HTTP 400 — Bad Request

What 400 actually means

The request itself is broken at a level the server refuses to guess about — bad syntax, a body that is not the JSON it claims to be, a header the server cannot parse, or a URL containing characters that should have been encoded. It is deliberately generic, which makes it the least helpful of the common errors: "400 Bad Request" alone tells you the server rejected the request but not which part offended it. Many APIs also use 400 for validation failures, though 422 is the more precise choice there.

Common causes

• Malformed JSON or XML in the request body — a trailing comma is the classic
• A required field missing or of the wrong type, where the API uses 400 for validation
• Invalid or unencoded characters in the URL or query string
• A corrupted or oversized cookie the server cannot parse
• Mismatch between `Content-Type` and the body actually sent
• An HTTP request sent to a port expecting HTTPS, or vice versa

If you're just trying to view the page

1. Clear cookies for that site — an oversized or corrupted cookie is a very common cause of a 400 that follows you around
2. Check the URL for typos, stray spaces, or characters that got mangled by copy and paste
3. Try the page in a private window or a different browser to rule out local state
4. Clear the browser cache and DNS cache if the error persists across pages on one site

If it's your site

1. Return a body saying which field or header failed; a bare 400 wastes everyone's time
2. Validate `Content-Type` and reject mismatches explicitly rather than failing to parse
3. Check header and cookie size limits — Nginx `large_client_header_buffers` and equivalents reject oversize headers as 400
4. Use 422 for semantically valid but unacceptable data, keeping 400 for genuinely unparseable requests
5. Log the raw request when returning 400 so you can see what the client actually sent

Reference

Status code

400

Reason phrase

Bad Request

Category

4xx — Client Error

Defined in

RFC 9110 §15.5.1