422 Unprocessable Entity (WebDAV; RFC 4918)
This is an educational reference page about HTTP 422 Unprocessable Entity. The page itself is served as 200 OK so it can be indexed as HTTP documentation.
The request was well-formed but was unable to be followed due to semantic errors.
What it means
HTTP 422 Unprocessable Entity means the request syntax is valid, but the instructions cannot be processed because of semantic validation errors.
Common causes
- Required fields are syntactically present but fail business validation.
- A value is well-formed but conflicts with domain rules, state, or constraints.
- The server understands JSON or form data but cannot apply the requested change.
Where you see it
- JSON APIs, form submissions, GraphQL mutations, Rails-style validation errors, and WebDAV requests.
- Create or update endpoints where the body parses correctly but fails business rules.
- Cases where retrying the same request will fail until the submitted values change.
Headers involved
- Content-Type should match the submitted format so the server can parse the body.
- Accept can influence whether the validation response is JSON, HTML, or another format.
- Problem Details responses often use application/problem+json for structured validation errors.
How to fix it
- Return field-level validation errors so clients can correct the request.
- Use 400 when the request syntax or framing is invalid.
- Keep validation messages stable enough for both humans and client applications.
Client fixes
- Read the response body and correct the specific field or rule that failed.
- Do not retry unchanged values unless the server says the failure was temporary.
- Validate required fields and value ranges before submitting.
Server fixes
- Return stable error codes and field paths for validation failures.
- Separate parser errors as 400 from semantic validation failures as 422.
- Document examples for common 422 responses so API clients can handle them predictably.
Example response
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json
{"errors":{"email":["is already taken"]}}Developer notes
422 is common in APIs and WebDAV. It is most useful when the client can change the submitted values and retry.
Questions
What does HTTP 422 mean?
HTTP 422 means the server understood the request format, but validation or business rules prevented processing.
What is the difference between 400 and 422?
Use 400 for malformed requests. Use 422 when the request is well-formed but semantically invalid.