Skip to content
Webmaster Tools
Inspect & debugHTTP Status Codes422 Unprocessable Content

422 Unprocessable Content

What HTTP 422 Unprocessable Content (Unprocessable Entity) means, how APIs like Rails, Laravel, FastAPI and GitHub use it for validation errors, and 422 vs 400.

All status codes

What 422 means

The server understood the request, the body is in a supported format and parses fine, but its contents are invalid, so it can't act on it. 422 is defined in RFC 9110 §15.5.21 as "Unprocessable Content". It started in WebDAV (RFC 4918 §11.2) as "Unprocessable Entity", the name most frameworks still use.

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

{
  "title": "Validation failed",
  "errors": [
    {"field": "email", "message": "is not a valid email address"},
    {"field": "start_date", "message": "must be in the future"}
  ]
}

Common causes

  • A required field is missing or empty.
  • A value fails a rule: an invalid email, a negative quantity, a date in the past, a string that's too long.
  • Wrong types: a string where the API expects a number, which schema validators such as FastAPI's report as 422.
  • References that don't resolve: an ID for a related record that doesn't exist.

Where you'll meet it:

  • FastAPI answers 422 with a detail array for any request that fails its Pydantic model.
  • Laravel returns 422 with an errors object when validation fails on a JSON request.
  • Rails uses status: :unprocessable_entity when a save fails; Turbo needs that 4xx to re-render the form with errors.
  • The GitHub API answers 422 "Validation Failed" with an errors list.

How to fix it as a client

Read the response body: a 422 almost always lists which fields failed and why. Fix those values and send the request again. Retrying the same request unchanged will fail the same way. If the error names a field you did send, check its type and format (dates as ISO 8601, numbers not quoted) against the API docs.

How to send it as a server

Use 422 when the syntax is fine but the data breaks your rules, and return every failing field at once so the client can fix them in one pass. A common split:

  • 400 Bad Request: the body can't be parsed at all (broken JSON) or the request is malformed.
  • 415 Unsupported Media Type: the body is in the wrong format.
  • 422: the body parses but fails validation.
  • 409 Conflict: valid data that clashes with stored state, such as a duplicate email.

Plenty of APIs use 400 for validation errors too; either is acceptable as long as you're consistent and the body explains the problem.

422 and SEO

422 comes from form submissions and API calls, which search engines don't make, so it has no direct SEO effect. If a page you want indexed answers 422 to a plain GET, Google treats it like any 4xx other than 429 and keeps it out of the index.

To see exactly which validation errors an API returns, send the request with the HTTP Request Builder.