422 Unprocessable Content - HTTP Status Code

Meaning & Description

The 422 Unprocessable Content status code (formerly known as Unprocessable Entity) indicates that the server understands the content type of the request entity, and the syntax of the request is correct, but it was unable to process the contained instructions. This is the standard status code used for validation errors in modern REST and GraphQL APIs. For example, if a client sends a structurally valid JSON payload, but a required field like `email` is missing or improperly formatted, the server returns a 422.

Common Causes

Failing schema validation (e.g., using libraries like Zod, Joi, or Pydantic).
Submitting a string to a field that expects an integer.
Violating unique constraints (though 409 Conflict is also sometimes used for uniqueness issues).

How to fix a 422 error

Read the error message in the response body. A good API will return an array of validation errors specifying exactly which fields failed.
Check the data types of the payload against the API documentation.
Ensure all required fields are present in the request body.

Browser & SEO Behaviour

Browser Behavior

Browsers handle this transparently. Fetch/XHR will resolve successfully, and the JavaScript application must check `response.ok` or `response.status === 422` to display validation errors on the form.

SEO Impact

No direct SEO impact, as form submissions and API mutations are not performed by crawlers.

CDN Behavior

CDNs will typically pass this response directly to the client without caching it.

Code Examples

HTTP

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

{
  "errors": [
    { "field": "email", "message": "Invalid email format" },
    { "field": "age", "message": "Must be greater than 18" }
  ]
}

Node.js (Express (Zod))

import { z } from "zod";

const userSchema = z.object({ email: z.string().email() });

app.post("/users", (req, res) => {
  const result = userSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(422).json({ errors: result.error.errors });
  }
  res.send("Success");
});

Python (FastAPI)

# FastAPI automatically returns a 422 with a detailed JSON response when Pydantic validation fails.
from fastapi import FastAPI
from pydantic import BaseModel, EmailStr

app = FastAPI()

class User(BaseModel):
    email: EmailStr

@app.post("/users")
async def create_user(user: User):
    return {"message": "Success"}

Go (net/http)

func handler(w http.ResponseWriter, r *http.Request) {
    // Assuming JSON is already parsed into a struct successfully
    if user.Age < 18 {
        w.WriteHeader(http.StatusUnprocessableEntity)
        w.Write([]byte(`{"error": "Age must be >= 18"}`))
        return
    }
    w.WriteHeader(http.StatusOK)
}

C# (ASP.NET Core)

// ASP.NET Core automatically returns 400 for model validation by default.
// To return 422 instead, you configure the ApiBehaviorOptions:
// builder.Services.Configure<ApiBehaviorOptions>(options => 
//     options.InvalidModelStateResponseFactory = context => 
//         new StatusCodeResult(422));

cURL

# Sending a string for an age field that expects an integer
curl -X POST https://api.example.com/users -d '{"name": "Alice", "age": "twenty"}' -H "Content-Type: application/json"

Raw HTTP Response Example

HTTP Response

HTTP/1.1 422 Unprocessable Content
Date: Wed, 21 Oct 2026 07:28:00 GMT
Content-Type: application/json

{"error": "Invalid email address."}

Real-world Examples

GitHub API: Returns a 422 when creating a repository with an invalid name, or when an issue payload fails validation.

Stripe API: Often returns a 400 or 422 depending on the endpoint when credit card parameters are missing or structurally invalid.

Laravel: The Laravel PHP framework returns a 422 status code automatically when form validation rules fail.

Frequently Asked Questions

What is the difference between 400 Bad Request and 422 Unprocessable Content?

Use 400 when the JSON syntax is broken (e.g., a missing comma) and cannot be parsed. Use 422 when the JSON is perfectly valid, but the data inside violates business rules (e.g., a missing required field or a string that should be a number).

Why was the name changed from Unprocessable Entity to Unprocessable Content?

RFC 9110 updated the terminology across the HTTP spec to replace the word "Entity" with "Content" for clarity, resulting in the new name.

Should I return an array of errors with a 422?

Yes, it is considered best practice. A 422 response should include a structured JSON body detailing exactly which fields failed validation and why, so the client can display them next to the appropriate form inputs.

Did You Know?

The 422 status code was originally created as an extension to HTTP for WebDAV (RFC 4918), but it proved so useful for validation errors that it was adopted universally by REST APIs.

FastAPI (Python) relies entirely on 422 to communicate validation failures generated by Pydantic.

Developer Tips

Standardize your 422 response body across your entire API. A common format is `{ "errors": [ { "field": "email", "message": "Required" } ] }`.
Do not use 422 for authentication or authorization failures (use 401 and 403).
If a resource already exists and a unique constraint fails, consider using 409 Conflict instead of 422, though both are acceptable depending on your API design.

Interview Questions

These are questions you might face in a backend or API design interview that touch on HTTP 422.

If a client sends an empty string for an email field that requires a valid email format, what HTTP status code should the server return?

It should return a 422 Unprocessable Content. The syntax of the request is correct (it parsed as a string), but the semantic value (empty string) violates the validation rules.

Why is 422 preferred over 400 for validation errors in modern APIs?

Because 400 strictly means "Bad Request" (often implying malformed syntax like invalid JSON). 422 distinguishes between a request the server literally couldn't parse (400) and one it parsed but rejected due to logic (422), making debugging much easier.

Common Interview Mistakes

Insisting that 400 Bad Request is the only code for validation errors.
Using the outdated name "Unprocessable Entity" without acknowledging the shift to "Unprocessable Content" in recent RFCs (though both are generally accepted in interviews).