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

What 400 Bad Request means

RFC 9110 defines 400 as the server's way of saying the request could not be understood because of malformed syntax. The key word is syntax: the server is not evaluating who you are, what you are allowed to do, or whether the resource exists. It is saying the request itself, as bytes on the wire, does not parse as a valid HTTP request. That can be the request line, the headers, or the body, depending on where the parser gives up.

How the error appears

Browsers render whatever plain error page the server sends back for a 400; there is no dedicated browser-level page the way there is for a DNS or certificate failure, since the connection succeeded and a response did arrive. A common variant reads exactly "400 Bad Request - request header or cookie too large," which names the cause directly. From the command line:

curl -I https://example.com/some/path
HTTP/1.1 400 Bad Request
Content-Type: text/html

Server logs are the most useful evidence here, because unlike a TLS handshake failure, the request did reach the application layer and gets logged, often with the specific header or line that failed to parse.

What causes a 400 Bad Request

For a visitor, in the order you are most likely to actually hit them:

• Oversized or corrupted cookies. Years of accumulated cookies for one domain, or a cookie that got mangled by an extension or a bad redirect, routinely produce the exact message "400 Bad Request - request header or cookie too large" once the total header size crosses the server's limit.
• A mistyped or badly encoded URL. A stray character, an unencoded space, or a broken percent-encoding sequence in the address bar or a pasted link can fail to parse as valid syntax.
• A browser extension modifying requests. Ad blockers, privacy tools, and some VPN extensions rewrite headers or the request line, and a bug in one of them can hand the server something malformed.
• A cached redirect pointing at a broken URL. The browser follows a stale redirect to a URL that is itself invalid, and the 400 shows up on the destination, not the link you actually clicked.
• A file upload larger than the server allows. Some server configurations answer an oversized upload with 400 rather than the more specific 413 Payload Too Large.

For the site owner, roughly in the order worth checking first:

• Header or cookie size limits set too low for what the application actually sends, especially after adding tracking cookies, JWTs in headers, or a session mechanism that grows over time.
• An invalid or missing Host header, which a reverse proxy or a misconfigured client can produce, and which most servers require to route the request at all.
• A Content-Length that does not match the body actually sent, which a broken client or a buggy proxy in the middle can cause.
• Web application firewall or ModSecurity rules rejecting a request whose syntax looks fine to a human but matches a defensive pattern the WAF treats as malformed.
• An API deliberately rejecting malformed JSON with 400. This one is correct behavior, not a bug: a request body that fails to parse as valid JSON, or is missing a required field the API validates at the syntax level, should return 400 by design.

How to tell whose fault it is

Reproduce the same request from a clean environment: a private browsing window with no extensions and no accumulated cookies, or a plain curl call to the same URL. If the clean request succeeds, the cause was local, most often cookies or an extension. If it fails identically from a clean client and from somewhere else entirely, the server's own limits or rules are rejecting a legitimately-formed request, and the fastest way to confirm that at scale is to run an HTTP check from several locations at once and compare the status code each one gets back.

How to fix a 400 Bad Request

If you are a visitor

1. Clear cookies for the site first, since oversized or corrupted cookies are by far the most common cause. Most browsers let you clear cookies for one site without wiping every other login.
2. Retry in a private or incognito window. A clean window has no accumulated cookies and, depending on the browser, disables most extensions by default, which isolates both common causes at once.
3. Check the URL for typos or stray characters, especially after pasting a link from somewhere that may have added tracking parameters or broken the encoding.
4. Disable extensions one at a time if the error persists in a normal window but not in private browsing, to find which one is rewriting the request.
5. Try a different device or network to rule out a captive portal or a local proxy that is not related to the site at all.

If you run the site

1. Raise header and buffer limits if the application genuinely needs them larger. On nginx:

   large_client_header_buffers 4 16k;

   On Apache:

   LimitRequestFieldSize 16384

   On IIS, check both maxRequestLength in web.config for the request body and the HTTP.sys MaxFieldLength registry setting for individual header fields.
2. Reduce what you are actually sending in cookies and headers instead of only raising the ceiling. Trimming stale cookies, moving large tokens out of headers, and setting shorter cookie lifetimes prevents the problem from recurring as usage grows.
3. Check the Host header handling at the reverse proxy or load balancer, and confirm it is forwarding a valid, expected value to the application.
4. Read the WAF or ModSecurity logs for the specific rule that fired, if one is in front of the application; a false positive there needs a scoped exception, not a disabled ruleset.
5. Confirm a 400 from your API is intentional before "fixing" it. A malformed JSON body or a field that fails validation at the syntax level should return 400; the fix in that case is clearer client-side error messages, not changing the status code.

400 versus similar codes

• 401 Unauthorized means the request was understood fine, but valid credentials are missing or were rejected.
• 403 Forbidden means the request was understood fine, but the server refuses to authorize it regardless of credentials.
• 404 Not Found means the request was understood fine and no resource matched the path.
• 413 Payload Too Large is the specific code for a body that exceeds a size limit, though some servers answer 400 instead in practice.
• 414 URI Too Long is the specific code for a request line that exceeds a length limit.
• 422 Unprocessable Content means the syntax parsed fine but the semantics did not, for example valid JSON with a value that fails business validation, a finer distinction than most APIs bother making from 400.

How to prevent a 400 error taking a page down

A 400 introduced by a deploy that tightened header limits, or a WAF rule update that starts matching legitimate traffic, will not show up as a crash or a timeout, since the server answers instantly and correctly by its own rules. A scheduled HTTP check with an assertion on the expected status code catches that the moment it starts happening, rather than waiting for support tickets to pile up. Combined with monitoring from multiple locations, it also tells you whether the 400 is universal or tied to one region's edge configuration.

Related errors

The wider family of client and server error codes is covered in the 4xx status code overview. See also 403 Forbidden for requests the server understood and refused, 404 Not Found for requests aimed at a resource that does not exist, and 429 Too Many Requests for requests rejected because of rate rather than syntax.

Frequently asked questions

Why does clearing cookies fix a 400 error?

Because cookies ride along as request headers on every request, and a server enforces a maximum total header size. Years of accumulated cookies, or one corrupted cookie, can push the total past that limit, and the server answers 400 before reading anything else about the request.

Is a 400 error the same on every website I visit?

The code and the general cause, malformed request syntax, are the same everywhere, but the exact limit that got crossed and the exact wording of the error page are set by each site's own server configuration.

Should my API return 400 for invalid input?

Yes, when the input fails to parse or is missing a field the API checks at the syntax level. That is 400 working as intended, not a bug to fix by relaxing validation.

Can a WAF cause a 400 error on a request that looks completely normal?

Yes. A WAF rule can flag a pattern in a URL, header, or body that is technically valid HTTP but matches a defensive signature, and some WAF configurations answer with a generic 400 rather than a more specific block page.

What is the difference between 400 and 413?

413 is the specific code for a request body that exceeds a configured size limit. Many servers use it correctly, but some answer 400 instead for the same oversized-body condition, so do not assume the code alone tells you the exact cause without checking the server's own documentation or logs.