422 Unprocessable Content (formerly Unprocessable Entity)

This is an educational reference page about HTTP 422 Unprocessable Content. The page itself is served as 200 OK so it can be indexed as HTTP documentation.

The server understands the content type and the syntax is correct, but it cannot process the instructions in the request. RFC 4918 called this 422 Unprocessable Entity.

Specification

Registered in the IANA HTTP Status Code Registry as Unprocessable Content. Defined in RFC 9110, Section 15.5.21.

What it means

HTTP 422 Unprocessable Content means the request body is well-formed and in a supported media type, but the server cannot act on what it says. RFC 9110 moved 422 from WebDAV (RFC 4918, where it was Unprocessable Entity) into core HTTP. In APIs, 422 is the common response for field validation errors.

When to use it

Return 422 when JSON parses but a field breaks a rule, such as an end date before the start date.
Return 422 when a value has the right type but is outside the allowed set, such as a currency code the service does not support.
Return 400 when the body does not parse, and 415 when the media type is wrong.

Common causes

Missing required fields in otherwise valid JSON.
Values that break business rules, such as a quantity of 0 or a password that is too short.
References to records that do not exist, such as a foreign key in the body.

Where you see it

Signup, checkout, and settings forms backed by JSON APIs.
FastAPI, which returns 422 for request validation errors by default, and Rails scaffolds, which return 422 when a save fails validation.
Public APIs such as GitHub's REST API, which uses 422 for validation failures.

Headers involved

Content-Type on the request must be one the server supports. Otherwise the answer is 415, not 422.
Content-Type: application/problem+json on the response marks an RFC 9457 error body.

Client fixes

Read the field errors in the response and correct those values.
Run the same validation on the client before sending, for faster feedback.
Do not retry without changing the input. The same body gets the same 422.

Server fixes

Return every field error at once, not just the first.
Use stable error codes and field paths, such as a JSON Pointer, so clients can map errors to inputs.
Keep the 400 vs 422 rule the same on every endpoint.

Examples

Field validation errors with Problem Details

POST /api/bookings HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "room": "A2",
  "start": "2026-11-03",
  "end": "2026-11-01",
  "guests": 0
}

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

{
  "type": "https://api.example.com/problems/validation",
  "title": "Booking has invalid fields",
  "status": 422,
  "errors": [
    {
      "pointer": "#/end",
      "detail": "must be after start"
    },
    {
      "pointer": "#/guests",
      "detail": "must be at least 1"
    }
  ]
}

Common mistakes

Returning 422 for JSON that does not parse. That is 400.
Returning 422 for a missing or wrong Content-Type. That is 415.
Returning 200 with an errors array. Clients and monitors see a success.

Developer notes

Older clients and docs say 422 Unprocessable Entity. The code and meaning are the same; only the name changed when RFC 9110 brought 422 into core HTTP.

Questions

What does HTTP 422 mean?

HTTP 422 Unprocessable Content means the request is well-formed and in a supported format, but the server cannot process its contents, usually because of validation errors.

Is 422 Unprocessable Entity the same as 422 Unprocessable Content?

Yes. RFC 9110 renamed it from the WebDAV name Unprocessable Entity. The meaning did not change.

Should validation errors return 400 or 422?

A common rule is 400 for requests that do not parse and 422 for parsed requests whose values fail validation. Either works if the whole API follows the same rule.

Header and content rules

RFC 9110 adds no header or content rule specific to 422. The 4xx class rules also apply. See 422 in the response obligations table.

Related comparisons

400 vs 411 vs 413 vs 422 Request Errors

Related API error guide

Use RFC 9457 Problem Details to add a standard application/problem+json body without changing the meaning of HTTP 422.