HTTP 400 Bad Request

Quick reference

What HTTP 400 means

RFC 9110 describes 400 as the server indicating that it cannot or will not process the request due to something perceived to be a client error. The phrase "perceived to be" matters: the server is not required to exhaustively verify that the request is malformed before returning 400 — it only needs to determine that it cannot process the request as sent.

400 is the catch-all for client-caused request failures that do not fit a more specific 4xx code. If the client is missing authentication credentials, 401 is correct. If the client is authenticated but lacks permission, 403 is correct. If the resource does not exist, 404 is correct. If the payload is syntactically valid but semantically wrong, 422 is more precise. When none of those apply and the request is simply malformed, 400 is the right code.

The key characteristic of a 400 is that retrying the identical request will produce the same 400. The error is in the request itself, not in a transient server condition. The client must change something about the request before retrying.

Common causes

Malformed request syntax

The request line, headers, or body contain characters or structure that the server's HTTP parser cannot interpret. This includes invalid characters in the URL, header names that violate RFC syntax, or a request line missing the HTTP version. Servers reject these at the protocol parsing layer before any application logic runs.

Invalid or missing Content-Type header

A POST or PUT request with a body requires a Content-Type header that accurately describes the body format. Sending JSON without Content-Type: application/json will cause many servers to misparse or reject the body. Sending a Content-Type: application/json header with a non-JSON body produces the same result. The server needs to know how to parse the body before it can read it.

Malformed JSON or XML in the request body

If the body is supposed to be JSON or XML, any syntax error — a trailing comma, an unclosed bracket, invalid Unicode escape, or a bare string outside an array or object — causes the parser to fail and the server to return 400. Validate body payloads with a local parser before sending.

Missing or invalid required parameters

Many API endpoints require specific query parameters, path parameters, or body fields. When a required parameter is missing, empty, or of the wrong type — a string where an integer is expected, a negative number where only positive values are valid — servers typically return 400. The response body should indicate which parameter failed and why.

URL too long or headers too large

HTTP servers have configurable limits on URL length and total header size. Exceeding these limits produces a 400 (or sometimes 431 Request Header Fields Too Large for the header case). This commonly occurs with URLs that encode large amounts of data in query parameters, or requests that accumulate many cookies over time until the Cookie header exceeds the server's limit.

Invalid encoding or character set issues

Requests with incorrectly percent-encoded URL components, double-encoded characters, or null bytes in path segments will fail parsing on strict servers. Some web servers also reject requests with header values containing non-ASCII characters without proper encoding, returning 400 before the request reaches application code.

WAF or proxy rejection

Web Application Firewalls (WAFs) and reverse proxies can return 400 when they detect patterns that match attack signatures — SQL injection in query parameters, oversized cookies, unusual header combinations. These 400s are generated before the request reaches the origin server. A request that works in development but gets 400 in production is often hitting a WAF rule.

How to diagnose a 400 error

1. Read the response body. A well-implemented server includes an error description in the 400 response body. It should tell you what was wrong — which field failed, what was expected, or what syntax error was detected. Start here before investigating further.
2. Log the full request. Capture the exact URL, HTTP method, all headers, and the complete request body as they were sent. Tools like curl with -v, Postman's console, or browser DevTools Network tab show the raw request. The 400 is caused by something in one of these elements.
3. Validate the body payload independently. If the request includes JSON, run it through a JSON validator. If it includes XML, validate against the schema. Parse errors are often invisible when constructing request bodies programmatically — a missing comma or unescaped quote produces a valid-looking string that is not valid JSON.
4. Check required headers. Confirm Content-Type matches the actual body format. Confirm Content-Length is accurate if set. Check that authentication headers (Authorization, API keys) are present if required by the endpoint.
5. Test with a minimal request. Strip the request to the minimum required fields and test whether that returns 200. Then add fields back one at a time to identify which field triggers the 400. This binary search approach quickly isolates the problematic element.
6. Check server logs. If you control the server, check application logs for a parse error or validation failure message corresponding to the timestamp of the 400. The server's log often contains the specific reason that was not returned to the client.
7. Test bypassing the WAF or proxy. If the request works when sent directly to the origin server but fails through the proxy or CDN, the 400 is coming from infrastructure, not your application. Review WAF rules for false positives.

400 vs related 4xx codes

400 vs 422 — choosing the right code

400 and 422 are both client errors for invalid requests, but they signal different failure types. Use 400 when the request is syntactically broken — the server cannot parse it as a valid HTTP request with a valid body. Use 422 Unprocessable Content when the request is syntactically valid and the server parsed the body successfully, but the content fails business logic validation: a required field is missing from an otherwise valid JSON object, a value is outside an accepted range, or a field references a resource that does not exist.

The practical rule: if the error occurs during parsing, return 400. If the error occurs during validation after parsing succeeds, return 422. This distinction helps clients implement specific error handling — 400 means fix the format, 422 means fix the data.

What the response body should contain

A bare 400 with no response body is technically valid but forces clients and developers to guess why the request failed. Well-designed APIs include a structured error body with enough detail to fix the request without guessing. A useful 400 response body for a JSON API includes an error code (machine-readable), a message (human-readable), and when possible, a field-level breakdown listing which parameters failed and why.

Example structure for a JSON API:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "validation_failed",
  "message": "Request body contains invalid fields",
  "details": [
    { "field": "email", "message": "Invalid email format" },
    { "field": "age", "message": "Must be a positive integer" }
  ]
}

This level of detail reduces the number of back-and-forth debug cycles between client and server developers, and reduces support requests from API consumers.

FAQ

What does HTTP 400 Bad Request mean?

HTTP 400 means the server received the request but cannot process it because of an error in the request itself — malformed syntax, invalid headers, bad payload structure, or a request that violates the server's expected format. The server is not broken; the request is.

What is the difference between 400 and 422?

HTTP 400 is used for requests that are syntactically malformed — the server cannot parse them. HTTP 422 Unprocessable Content is for requests that are syntactically valid but semantically invalid — the server parsed the body but the data fails validation rules. Use 400 for parse failures and 422 for validation failures.

Should I retry a request after a 400 error?

No. A 400 means the request itself is wrong, and retrying the same request will produce the same result. Fix the request before retrying. Automatic retry logic should not retry 400 responses.

Can a 400 error be caused by the server?

Rarely, but yes. Overly strict input validation, misconfigured WAF rules, or proxy header manipulation can produce 400s that appear to be client errors but are caused by server-side misconfiguration. If the request appears correct and you are still getting 400, inspect the full request as it arrives at the server.

What should a 400 response body contain?

The 400 response body should describe what was wrong with the request. For APIs, this means a JSON body with an error code, a human-readable message, and ideally a field-level breakdown of what failed. A bare 400 with no body forces clients to guess why the request failed.

Related resources

On this site: HTTP 400 troubleshooting guide · HTTP 401 Unauthorized · HTTP 403 Forbidden · HTTP 404 Not Found · HTTP 422 Unprocessable Content · HTTP 431 Request Header Fields Too Large · All 4xx client errors

Comparisons: 400 vs 422 · 400 vs 404 · 400 vs 401

Standards: RFC 9110 §15.5.1 · IANA HTTP Status Code Registry · MDN Web Docs: 400