HTTP status · 4xx — client error
422 Unprocessable Content
422 Unprocessable Content means the request was well formed but its instructions could not be processed.
Key facts
| Class | 4xx — client error |
|---|---|
| Standard | RFC 9110 §15.5.21; WebDAV RFC 4918 |
| Cacheable by default | No |
| Typical use | Field validation, semantic errors |
| Fix side | Client corrects the payload |
What 422 means
The server understood the syntax and the request was not malformed, but it cannot carry out the instruction — a required field is missing, a date is out of range, or a referenced resource violates a business rule. Many JSON APIs use 422 for validation failures because 400 is ambiguous about whether parsing or semantics failed.
Making 422 useful
Return a machine-readable list of field errors, not just a sentence. A body like {"errors":[{"field":"email","code":"invalid"}]} lets a client highlight the right input. Do not return 422 for malformed JSON — that is 400 — and do not return 200 with an error payload, which hides failures from monitoring.
Frequently asked questions
Is 422 the same as 400?
400 covers requests the server cannot parse or that violate the protocol. 422 is for requests that parse correctly but fail semantic validation.
Why do some APIs use 400 for validation instead of 422?
Both are defensible. 422 is more precise, but 400 is older and widely understood; consistency within an API matters more than the choice.