400 Bad Request means the server looked at your request and said "I can't make sense of this." It's a 4xx client error — the problem is in what was sent, not in the server. And for visitors, the cause is usually one specific, easily-fixed thing: cookies.
The #1 cause for visitors: cookies
By far the most common 400 a normal user hits is "400 Bad Request — Request Header Or Cookie Too Large." Over time a site can pile up cookies until the request header exceeds the server's size limit, and the whole request gets rejected. The fix is simple:
- Clear that site's cookies (site settings → cookies → remove), then reload.
- Double-check the URL for typos or stray characters.
- Clear your cache or try a private window.
Common causes (developer view)
| Cause | What's happening |
|---|---|
| Oversized cookie/header | Request header exceeds the server limit |
| Malformed URL / query | Invalid characters or broken encoding |
| Invalid JSON body | Syntax error in the request payload |
| Wrong Content-Type | Body doesn't match the declared type |
| Missing required field | API validation rejects the request |
How to fix it — as a developer
- Reproduce with the raw request. Use
curl -vto see exactly what's sent. - Validate the body. Malformed JSON and a mismatched
Content-Typeare classic API 400s. - Check header/cookie limits. Tune
large_client_header_buffers(Nginx) if legitimate requests are large. - Return helpful 400s. Your API should tell the client which field is invalid — see API error handling best practices.
400 vs the rest
A 400 is the client's fault (bad request). Contrast with 500 (server's fault), 401 (not authenticated), and 403 (not allowed). If you're seeing a flood of 400s on an API endpoint, it's usually a client integration sending the wrong shape — worth catching early.
Nurbak Watch tracks 4xx rates per endpoint, so a spike of 400s from a broken client integration surfaces immediately instead of as silent failed requests.