400 Bad Request: what it means and how to fix it

A 400 Bad Request means the server couldn't process the request because something in it was malformed. Common causes, from cookies to bad JSON, and fixes.

1. The short answer

A 400 Bad Request error means the server won't process your request because something in it looks wrong: the address, the headers, the cookies or the data sent. For visitors, the most common cause by far is a corrupted or oversized cookie for that site, and clearing that site's cookies fixes it. For developers, it's usually a malformed request body, such as invalid JSON.

It's a 4xx code, so the server is saying the problem is in the request. Compare a 500, where the request was fine and the server failed.

2. What you'll see

"400 Bad Request", "Your browser sent a request that this server could not understand" (Apache), "400 Bad Request: Request Header Or Cookie Too Large" (nginx), or "The plain HTTP request was sent to HTTPS port" (nginx again). APIs usually return a short message in the body naming the bad field.

3. Common causes

• Cookies too large or corrupted. A site keeps adding cookies, or one gets mangled, until the server refuses the headers.
• A malformed address. A stray % not followed by two hex digits, spaces, or characters copied from a document that aren't allowed in a URL.
• Invalid JSON or form data sent to an API, or a body that doesn't match its Content-Type.
• Plain HTTP sent to an HTTPS port, for example http://example.com:443.
• Headers that are too big, such as a very long authorization token or referrer.
• A missing or wrong `Host` header, usually from a hand-made request or a misconfigured proxy.
• An expired or tampered token in the address, such as an old password-reset or sign-in link, which some apps answer with 400.

4. How to fix a 400 as a visitor

1. Check the address for typos and odd characters, or go to the site's home page and navigate from there.
2. Try a private window. If it works there, the problem is your cookies or cache for that site.
3. Clear cookies for that one site. In Chrome: click the icon left of the address, then Cookies and site data, and delete them. Other browsers have the same option in their site settings.
4. If you were uploading a file, try a smaller one (a file that's too big usually gives 413, but some servers say 400).
5. Turn off extensions that change requests, such as privacy or header tools, and try again.

Flushing DNS rarely helps with a 400: the server was reached, it just didn't like the request.

5. How to fix a 400 on your own site

Find out which part of the request the server rejected. The server's error log, or your app's log with the request's headers and body size, usually says.

nginx. Request Header Or Cookie Too Large means a header line or the headers together didn't fit large_client_header_buffers (4 buffers of 8 KB by default). Shrink the cookies first; raise the limit only if you must. The plain HTTP request was sent to HTTPS port means a link or redirect uses http:// with port 443; fix the redirect.

# nginx: allow bigger header lines (fix the cookies too)
http {
    large_client_header_buffers 4 16k;
}

Apache and cPanel hosting. Size of a request header field exceeds server limit comes from LimitRequestFieldSize, 8,190 bytes by default. As on nginx, find what's growing (often cookies from plugins or analytics) before raising it.

Node and Express. express.json() answers 400 when the body isn't valid JSON, and the error says where it failed. Make sure clients send Content-Type: application/json with a real JSON body. Validate input and return a clear message naming the field, rather than a bare 400.

# Reproduce an API request exactly
curl -i -X POST https://api.example.com/items \
  -H "Content-Type: application/json" \
  -d '{"name": "Test"}'

Next.js. Node's HTTP server, which Next.js runs on in production, limits the total size of request headers (16 KB by default in current versions), so a pile of cookies can trigger a 431 Request Header Fields Too Large there. Keep session cookies small and store data on the server, not in the cookie.

WordPress. Oversized cookies from plugins are the usual cause. Clear your cookies, then deactivate plugins one by one to find the one setting them.

Cloudflare. Cloudflare also rejects requests with headers above its limits. If a 400 page has Cloudflare branding and no request reached your server's log, shrink the headers.

6. On Cloudzyro

Sites & Apps sites sit behind Cloudflare, so its request limits apply in front of your app. If an app you deploy answers 400, it comes from your app's own code or framework: read its log, and check the request your page sends in the browser's Network tab. If a new version caused it, restore the previous version while you fix it.

7. How to check the status code

# Headers only
curl -I "https://www.example.com/page"

# Send no cookies at all: if this works, cookies are the cause
curl -I -H "Cookie:" "https://www.example.com/page"

In a browser, open developer tools, choose the Network tab and reload. Click the request to see its status, the request headers you sent (look at the size of cookie) and the response.

8. Related errors

• [401 Unauthorized](/guides/401-unauthorized): the request is fine, but you need to sign in.
• [403 Forbidden](/guides/403-forbidden-error): the request is fine, but not allowed.
• [404 Not Found](/guides/what-is-a-404-error): the address is valid, but nothing is there.
• [405 Method Not Allowed](/guides/405-method-not-allowed): wrong kind of request for that address.
• [413 Content Too Large](/guides/413-request-entity-too-large): the body is too big.
• 431 Request Header Fields Too Large: a more specific code some servers use for oversized headers.

9. Sources

• RFC 9110, section 15.5.1: 400 Bad Request
• MDN: 400 Bad Request
• nginx: large_client_header_buffers
• Apache: LimitRequestFieldSize
• Node.js: --max-http-header-size