Unprocessable Content

Active

RFC 9110 §15.5.21•Since 2004•REST APIs, form validation

HTTP 422 Unprocessable Content indicates the server understands the content type and syntax but cannot process the contained instructions. Defined in RFC 9110 §15.5.21. The request is well-formed but semantically invalid.

Description

The 422 Unprocessable Content status code indicates that the server understands the content type of the request content, and the syntax of the request content is correct, but it was unable to process the contained instructions.

This is distinct from 400 Bad Request — 400 means the request is malformed (bad syntax), while 422 means the syntax is fine but the data is semantically wrong.

Examples

Valid JSON, invalid data

http

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

{"email": "not-an-email", "age": -5}

422 with validation errors

http

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

{"errors": [{"field": "email", "message": "Invalid email format"}, {"field": "age", "message": "Must be a positive number"}]}

Edge Cases

•Use 422 for validation errors where the JSON/XML is syntactically valid but data is wrong.
•Include specific field-level error details in the response body.
•Some frameworks (Rails, Laravel) use 422 as their default validation error response.

When You'll See This

→Email field doesn't contain valid email
→Required field is empty
→Number is out of valid range
→Date is in the past when future is required

Implementation References

Language	Constant
Go	http.StatusUnprocessableEntity
Rust	http::StatusCode::UNPROCESSABLE_ENTITY
Python	http.HTTPStatus.UNPROCESSABLE_ENTITY
Node.js	http.STATUS_CODES[422]
.NET	HttpStatusCode.UnprocessableEntity
Java	(no built-in constant, use 422 literal)

History

Originally from WebDAV (RFC 4918, 2007). Adopted into HTTP/1.1 core with RFC 9110 (2022). Previously considered a WebDAV extension, now officially part of HTTP.

Related Status Codes

400 Bad Request 409 Conflict

Related Headers

Content-Type

FAQ

When should I use 422 vs 400?

Use 400 when the request can't be parsed (malformed JSON). Use 422 when the JSON is valid but the data doesn't pass validation (wrong email format, missing required fields).

How should I structure 422 error responses?

Include a structured errors array with field names and messages. This lets clients display field-specific validation errors.

Source: RFC 9110 §15.5.21