HTTP 422 Unprocessable Content

Quick reference

What HTTP 422 means

RFC 9110 defines 422 as indicating that the server understands the content type of the request entity and the syntax of the request entity is correct, but it was unable to process the contained instructions. The key phrase is "syntactically correct" — the body was parseable as the declared content type, but its meaning or values failed validation.

422 was originally defined in the WebDAV extension (RFC 4918) and adopted into the main HTTP specification in RFC 9110. It fills the gap between 400 (request cannot be parsed) and 403 (access denied): the request was parsed successfully, but the data it contains cannot be processed as submitted.

The practical difference from 400 Bad Request: use 400 when the server cannot parse the request (malformed JSON, invalid content type, broken syntax). Use 422 when the request parses cleanly but the data values fail validation — a required field is null, an email address format is wrong, an integer is outside the allowed range, or a referenced resource does not exist.

Common causes

Missing required fields

The JSON body was valid and parseable, but a field the endpoint requires was absent or null. The request structure is correct; the content is incomplete. A 422 with a body indicating which fields are missing gives the client exactly what it needs to fix the request.

Invalid field values

A value that does not meet validation constraints: a negative number where only positive values are accepted, a string that fails a regex pattern, a date in the wrong format, an enum value not in the accepted set. The syntax was valid; the value was not.

Referential integrity violations

A POST body references a resource by ID that does not exist — creating a record with a user_id that has no matching user. The request is syntactically valid, but processing it would violate data integrity constraints. 422 is the correct signal before attempting to write the record.

Business logic constraint violations

Rules that go beyond field-level validation: attempting to add a duplicate entry, scheduling an appointment in the past, submitting a payment with an amount that exceeds the available balance. These are application-level invariants that the server enforces, and 422 is the appropriate response when they are violated.

Error response body

A 422 is only useful if its response body tells the client exactly what failed. Returning a bare 422 with no detail forces the client to guess which field was invalid and why. The response body should include machine-readable error codes and field-level details:

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{
  "error": "validation_failed",
  "message": "The submitted data is invalid",
  "errors": [
    {
      "field": "email",
      "code": "invalid_format",
      "message": "Must be a valid email address"
    },
    {
      "field": "birth_date",
      "code": "future_date",
      "message": "Birth date cannot be in the future"
    }
  ]
}

This structure allows client-side code to map error codes to localized messages, highlight specific form fields, and give users actionable feedback without requiring a server round trip to diagnose the problem.

422 vs 400 vs 409

FAQ

What does HTTP 422 Unprocessable Content mean?

HTTP 422 means the server understood and parsed the request, but the data in the request body failed validation. The syntax is correct; the content is not. The response body should describe which fields failed and why.

What is the difference between 400 and 422?

400 is for parse failures — the server cannot read the request. 422 is for validation failures — the server read the request but the data values are invalid. Use 400 for format errors, 422 for semantic errors.

Should I retry after a 422?

Not without changes. A 422 means the request data is invalid. Fix the field values according to the error details in the response body, then retry.

When did 422 become part of core HTTP?

422 was originally defined in RFC 4918 (WebDAV) and was incorporated into the main HTTP specification as RFC 9110 (published 2022), which officially supersedes RFC 7231.

Related resources

On this site: HTTP 422 Unprocessable Content — full guide · HTTP 400 Bad Request · HTTP 409 Conflict · HTTP 400 Bad Request · All 4xx client errors

Comparisons: 400 vs 422 · 422 vs 409

Standards: RFC 9110 §15.5.20 · IANA HTTP Status Code Registry · MDN Web Docs: 422