HTTP 400 Bad Request is the server saying "I could not understand what you sent me." Unlike a 403 (I understood and refuse) or a 404 (I understood and have nothing there), a 400 means the request never got far enough to be evaluated. That points the investigation at the request itself, not the resource.
What triggers it ¶
- An oversized cookie or header. The most common cause by a distance. Servers cap total header size — commonly 8KB — and a site that has accumulated dozens of tracking cookies can cross it. Clearing cookies for that one domain fixes it instantly, which is why "clear your cookies" is the standard advice.
- Malformed URL encoding — a stray
%that is not followed by two hex digits, or an unencoded space. - A body that does not match its Content-Type, most often invalid JSON sent as
application/json. - An invalid Host header, which is why a misconfigured proxy can 400 every request it forwards.
- Deliberate rejection by a WAF that returns 400 rather than 403 to avoid telling you it is a WAF.
Narrowing it down in three steps ¶
- Try a private window. No cookies, no extensions. If it works, you have a cookie or header problem, not a server problem.
- Try the same URL from a different client. If a plain request succeeds where the browser fails, the difference is in what the browser is adding.
- Inspect the response headers. Our header inspector shows what the origin returns for a bare request — if that comes back clean, the origin is fine and the fault is in your request.
400 vs. 422, and why the difference matters ¶
Some APIs return 400 for validation failures ("email is required"). Strictly, that is what 422 Unprocessable Entity is for: the request parsed fine, the values were unacceptable. If you are building an API, keeping them distinct matters — a 400 tells a client "your request was malformed, retrying identically is pointless", a 422 tells it "fix these fields." Many frameworks conflate them, so as a consumer, read the body.
If you run the server ¶
Two settings account for most 400s that are genuinely yours to fix. The first is header size: nginx's large_client_header_buffers and Apache's LimitRequestFieldSize both default to around 8KB, and a site that sets many cookies — or one behind an SSO that issues a large session token — can exceed it for logged-in users only. That produces the maddening pattern where anonymous visitors are fine and signed-in ones are not.
The second is URL length. Long query strings, particularly ones carrying encoded state or tracking parameters, can cross large_client_header_buffers too. If your 400s correlate with specific campaign links, that is the cause.
Log the actual reason. Most servers record a 400 without saying which rule triggered it, which turns a five-minute fix into an afternoon. Raising the log level on the affected vhost long enough to catch a few real ones is almost always faster than guessing.
The one case where a 400 is not the client's fault ¶
A proxy that rewrites requests can corrupt them on the way through: a duplicated header, a mangled Host, or a body whose length no longer matches its Content-Length. The symptom is a site that 400s everything through one path and works through another. If you can reach the origin directly and it behaves, the proxy is the suspect, and no amount of clearing cookies will help.
FAQ ¶
Why does clearing cookies fix a 400 error?
Because oversized cookies are the leading cause. Every cookie for a domain is sent on every request to it; once the header block exceeds the server's limit, the request is rejected before any application code runs. Clearing that domain's cookies drops the header back under the cap.
Is a 400 error my fault or the website's?
Usually yours — or your browser's. The exception is a misconfigured proxy or load balancer in front of the site, which can 400 everything regardless of what you send. If every page of the site 400s from multiple networks, it is theirs.
Can a 400 mean the site is down?
No. The server answered, which means it is running. A site that is genuinely down gives you no HTTP response at all.