400 Bad Request: what it means, why it happens and how to fix it

A 400 Bad Request error means the server won't process the request because it sees something wrong with the request itself. Unlike a 5xx error, the server is working; it is refusing what was sent. The usual causes are cookies or headers that are too large, a URL with characters that aren't properly encoded, or an API call with a malformed body.

The HTTP specification defines it this way: "The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)" (RFC 9110, section 15.5.1).

Common causes

• Cookies or headers that are too large. Each server caps header size. A site that sets many cookies, or one large session cookie, can push a visitor's requests over that cap.
• Characters in the URL that aren't encoded. Spaces, % signs and other special characters must be percent-encoded. Cloudflare returns a 400 when a request contains a special character that is not properly encoded (Cloudflare error 400).
• Contradictory message framing. A request that sends both Content-Length and Transfer-Encoding: chunked is malformed, because the two framing methods contradict each other. Cloudflare rejects these with a 400.
• An invalid API request. Wrong JSON syntax, a missing required parameter, or the wrong body for the endpoint. APIs usually describe the problem in the response body.
• A request cut off in transit. AWS lists a client that "closed the connection before sending the full request body" as one cause of a 400 from an Application Load Balancer (ALB troubleshooting).

Header size limits by platform

Sources: nginx core module, Apache core, AWS ALB.

nginx's documentation says "a request header field cannot exceed the size of one buffer as well, or the 400 (Bad Request) error is returned to the client", and that by default "the buffer size is equal to 8K bytes." The page nginx sends in that case is titled "400 Request Header Or Cookie Too Large".

Apache's documentation says the default "should not be changed" under normal conditions. Treat a raised header limit the same way: it hides the real problem, which is usually a cookie that grew far beyond what it needs.

How to diagnose a 400, step by step

1. Read the response body. APIs and many servers explain the error there:

   curl -i https://api.example.com/v1/items -H "Content-Type: application/json" -d '{"name": "test"}'
   

2. Try a clean request. Repeat the request with no cookies, from a private window or with curl. If the clean request works, cookies or other headers are the cause.

3. Measure the cookie header. In the browser's developer tools, open the failing request and look at the size of the Cookie header. Several kilobytes of cookies on one domain is a warning sign.

4. Check the URL encoding. Look for raw spaces, % signs not followed by two hex digits, or unencoded non-ASCII characters in the path and query string.

5. Read the server's error log at the same timestamp. nginx logs messages such as client sent invalid request and client sent too long header line.

Fixes

If cookies are too large

The lasting fix is on the site: stop setting cookies you don't need, store large data on the server and keep only an ID in the cookie, and scope cookies to the paths and subdomains that use them. Raise large_client_header_buffers in nginx only as a short-term measure:

http {
    large_client_header_buffers 4 16k;
}

If you are behind a load balancer or CDN, its own limit still applies. Raising nginx's buffers won't help if an ALB in front of it rejects the request first.

If URLs are malformed

Find where the bad URLs come from. Common sources are templates that put user input into links without encoding it, email campaigns that add tracking parameters with raw spaces, and old links with characters that were never encoded. Encode values with your language's URL-encoding function (encodeURIComponent in JavaScript, urllib.parse.quote in Python) at the point where the link is built.

If an API returns 400

Compare your request with the API's documentation for that endpoint: method, path, headers (especially Content-Type), and the body schema. Log the exact request your client sends. Libraries sometimes serialize data differently from what you expect, for example form encoding instead of JSON.

What visitors can do

Clear cookies for that one site and reload. Browsers let you delete a single site's data from their privacy or site settings, so you don't have to clear cookies for every site. If the 400 appears on a link you followed, check the link for strange characters, or open the site's homepage and navigate to the page from there.

How 400 errors affect Google Search

Google treats 400 like other client errors: "Google doesn't index URLs that return a 4xx status code" and URLs that were already indexed and now return one "are removed from the index" (Google Search Central). A 400 has no effect on crawl rate.

The risk is a 400 that real visitors never see. A firewall rule, a bot-protection setting or a malformed internal link can return 400 to Googlebot for pages that work in your browser. Check the codes your important URLs return from outside your own network, and test redirect chains with the redirect checker, since a redirect to a badly encoded URL can end in a 400.

For every status code and how Google handles it, see HTTP status codes.