HTTP 400 Bad Request vs 422 Unprocessable Content
Both 400 and 422 reject a client request due to problems with the input, but at different levels. A 400 means the request itself is malformed (bad syntax, missing headers), while a 422 means the request is well-formed but the content fails semantic validation (invalid field values, business rule violations).
Description
The server cannot process the request due to malformed syntax, invalid request message framing, or deceptive request routing.
When You See It
When sending malformed JSON, missing required fields, or invalid query parameters.
How to Fix
Check the request body format, validate all required fields, and ensure proper encoding.
Description
The server understands the content type and syntax, but was unable to process the contained instructions. Common in API validation errors.
When You See It
When form validation fails — correct syntax but invalid data (e.g., email format wrong, date in the past).
How to Fix
Check the response body for specific validation errors and correct the input data.
Key Differences
400 is a syntax error — the server cannot parse the request (malformed JSON, missing Content-Type, bad encoding).
422 is a semantic error — the request is syntactically valid but the data fails business logic validation.
400 is defined in the core HTTP spec (RFC 9110); 422 originated from WebDAV but is now widely adopted in REST APIs.
Use 400 when the request body cannot even be decoded; use 422 when the body is valid JSON but contains invalid values.
Many APIs use 400 for both cases; using 422 provides more precise error signaling to API consumers.
When to Use Which
Return 400 when the request cannot be parsed: malformed JSON, unsupported Content-Type, or missing required headers. Return 422 when the request is syntactically correct but semantically invalid: an email field contains 'not-an-email', a date is in the past when it must be future, or a referenced entity does not exist.