HTTP 400 Bad Request vs 422 Unprocessable Content

When designing or debugging RESTful APIs, determining which HTTP status code to return for client payload errors is a frequent architectural decision.

Two of the most widely discussed status codes for input errors are HTTP 400 Bad Request and HTTP 422 Unprocessable Content.

Core distinction: syntax versus semantics

The core difference centers on syntax versus semantics:

• HTTP 400 Bad Request: The server cannot parse or interpret the request because the syntax, framing, or protocol format is broken (e.g., malformed JSON syntax).
• HTTP 422 Unprocessable Content: The server successfully parsed the request body and recognized the content type, but cannot execute the instructions because the data violates semantic rules (e.g., a required string field is missing or an integer is negative).

What HTTP 400 Bad Request means

According to RFC 9110, an HTTP 400 status indicates that the server cannot or will not process the request due to something perceived to be a client error.

Common examples of 400 Bad Request include:

• Malformed JSON body (e.g., a missing closing bracket or trailing comma in strict parsers).
• Invalid HTTP request headers or oversized header blocks.
• Corrupted query parameter encoding.
• Deceptive routing or invalid URI framing.

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error": "bad_request", "message": "JSON parse error: Unexpected character at line 3"}

What HTTP 422 Unprocessable Content means

Standardized for general HTTP in RFC 9110 (originally defined in WebDAV), status 422 means the server understands the content type and the syntax of the request entity is correct, but the server was unable to process the contained instructions.

Common examples of 422 Unprocessable Content include:

• Valid JSON where an email field fails regex format validation.
• Missing a mandatory field required by the application schema.
• Providing an end date that occurs before a start date.
• Submitting a numerical quantity that falls outside allowable business boundaries.

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

{
  "error": "validation_error",
  "fields": {
    "email": "Must be a valid email address",
    "age": "Must be greater than 18"
  }
}

Syntax errors vs. semantic validation errors

To differentiate clearly:

1. Syntax level (400): If the JSON parser fails before your controller logic even runs, the error is syntactic (400 Bad Request).
2. Semantic level (422): If the JSON parser succeeds and converts the payload into an object, but your schema validator rejects the values, the error is semantic (422 Unprocessable Content).

Side-by-side comparison table

Feature	HTTP 400 Bad Request	HTTP 422 Unprocessable Content
Error Type	Syntax / Formatting / Protocol	Semantic / Business Logic
Parser Stage	Fails at deserialization / parsing	Passes deserialization; fails validation
Payload Format	Invalid JSON / XML / Headers	Valid JSON / XML matching Content-Type
HTTP Specification	RFC 9110 Section 15.5.1	RFC 9110 Section 15.5.21
API Design Role	Catch-all for malformed requests	Specialized for structured field validation

How to choose between 400 and 422 in API design

When architecting a web API:

• Option A (Fine-Grained): Use 400 Bad Request strictly for parser/syntax failures, and 422 Unprocessable Content for business validation and schema errors. This provides clear architectural differentiation to API consumers.
• Option B (Traditional): Use 400 Bad Request for all client-side payload issues (both syntax and validation) accompanied by a structured JSON error payload.

Neither approach violates HTTP standards. What matters most is maintaining consistency across all endpoints in your API.

What to check before changing code

1. Did the request payload fail at the JSON parsing layer or at the model validation layer?
2. Does your API documentation specify 422 for field validation errors?
3. Is your client library configured to handle 422 responses cleanly without treating them as unexpected server crashes?

Key takeaway

Use HTTP 400 Bad Request when the server cannot parse the raw request syntax. Use HTTP 422 Unprocessable Content when the syntax is valid but the business instructions or field values cannot be processed.