400 vs 422 Difference: Key REST API Status Code Comparison

The 400 Bad Request status code means the server cannot process the request due to malformed syntax or invalid data. The 422 Unprocessable Entity means the request syntax is correct, but the server cannot process the contained instructions because of semantic errors or validation failures.

Quick Comparison

Here is a quick side-by-side comparison of HTTP status codes 400 and 422.

Aspect	400 Bad Request	422 Unprocessable Entity
Meaning	Malformed request syntax or invalid request message	Well-formed request but semantic errors prevent processing
Syntax Validity	Invalid syntax or structure	Valid syntax and structure
Common Cause	Missing parameters, invalid JSON, wrong format	Failed validation rules, business logic errors
RFC Standard	RFC 7231	RFC 4918 (WebDAV extension)
Typical Use Case	Client sent bad data format	Client sent correct format but invalid content
Response Example	Malformed JSON body	JSON body with invalid field values

Key Differences

The 400 Bad Request status code is used when the server cannot understand the request due to incorrect syntax. This means the client sent data that the server could not parse or interpret, such as malformed JSON, missing required fields, or invalid query parameters. The server rejects the request immediately without further processing.

In contrast, 422 Unprocessable Entity indicates that the request syntax is correct and the server understood it, but the content has semantic errors. For example, the data might violate validation rules like a string being too short, a number out of range, or a business rule not met. The server processes the request but refuses to perform the action due to these logical errors.

While 400 is a generic client error for bad syntax, 422 is more specific to validation and semantic correctness. Note that 422 is defined in the WebDAV extension (RFC 4918) but is widely used in REST APIs for detailed validation feedback.

Code Comparison

Example of returning a 400 Bad Request response in a Node.js Express API when JSON is malformed or missing required fields.

javascript

const express = require('express');
const app = express();
app.use(express.json());

app.post('/user', (req, res) => {
  if (!req.body.name) {
    // Missing required field
    return res.status(400).json({ error: 'Missing required field: name' });
  }
  res.json({ message: 'User created' });
});

app.listen(3000);

Output

POST /user with body {} returns status 400 and JSON {"error":"Missing required field: name"}

422 Unprocessable Entity Equivalent

Example of returning a 422 Unprocessable Entity response in a Node.js Express API when the request body is syntactically correct but fails validation rules.

javascript

const express = require('express');
const app = express();
app.use(express.json());

app.post('/user', (req, res) => {
  const { name, age } = req.body;
  if (!name || name.trim() === '') {
    return res.status(422).json({ error: 'Name cannot be empty' });
  }
  if (age && age < 18) {
    return res.status(422).json({ error: 'Age must be 18 or older' });
  }
  res.json({ message: 'User created' });
});

app.listen(3000);

Output

POST /user with body {"name":"", "age":16} returns status 422 and JSON {"error":"Name cannot be empty"} or {"error":"Age must be 18 or older"}

When to Use Which

Choose 400 Bad Request when the client sends malformed data or invalid syntax that the server cannot parse. This includes invalid JSON, missing required fields, or wrong content types.

Choose 422 Unprocessable Entity when the request syntax is valid but the data fails validation or business rules. This helps clients understand that the format is correct but the content needs correction.

Using these codes correctly improves API clarity and helps clients fix errors efficiently.

Key Takeaways

400 Bad Request means invalid syntax or malformed request data.

422 Unprocessable Entity means valid syntax but semantic or validation errors.

Use 400 for parsing errors and 422 for business rule or validation failures.

422 is defined in WebDAV but widely used in REST APIs for detailed validation feedback.

Correct use of these codes improves client-server communication and error handling.