Developer
Encoders, converters & dev utilities
422 Unprocessable Content
HTTP 422 Unprocessable Content. The request was well-formed (syntax is valid) but is semantically invalid — the server understood it but cannot process the contained instructions. RFC 9110 renamed this from 'Unprocessable Entity'. When to use it: Return for REST/JSON validation errors — e.g. a syntactically valid body that fails business/field validation. It is a client-error (4xx) status, which means the problem is with the request and the caller must change something before retrying. (Reference: RFC 9110 §15.5.21.)
The request was well-formed (syntax is valid) but is semantically invalid — the server understood it but cannot process the contained instructions. RFC 9110 renamed this from 'Unprocessable Entity'.
- When to use: Return for REST/JSON validation errors — e.g. a syntactically valid body that fails business/field validation.
- How to handle: Fix the invalid field values described in the error body and resubmit.
- Reference: RFC 9110 §15.5.21
- Category: 4xx Client Error
Frequently asked questions
What does HTTP 422 mean?
HTTP 422 Unprocessable Content: The request was well-formed (syntax is valid) but is semantically invalid — the server understood it but cannot process the contained instructions. RFC 9110 renamed this from 'Unprocessable Entity'. It is a client-error (4xx) status, which means the problem is with the request and the caller must change something before retrying. It is defined in RFC 9110 §15.5.21.
When should an API return 422 instead of 400?
Return 400 Bad Request when the request itself is malformed — invalid syntax or a body that cannot be parsed. Return 422 Unprocessable Content when the body is syntactically valid (it parsed) but fails semantic validation, such as a missing required field or an out-of-range value. Using 422 for field-level validation errors lets clients distinguish "I could not read your request" from "I read it but it broke the rules".