400 400 Bad Request
The server cannot process the request due to client-side input errors.
What Is This?
The HTTP 400 Bad Request status code indicates that the server cannot process the request because of client-side errors. This includes malformed request syntax, invalid request message framing, or deceptive request routing. Unlike 422 (Unprocessable Entity) which indicates semantic validation failures, 400 is for structurally invalid requests that the server cannot parse or interpret.
Common Causes
Malformed JSON or XML in the request body
Invalid or missing required headers (Content-Type, Accept)
URL with invalid characters or excessive length
Request body exceeding server size limits
Examples
Ensure JSON, XML, or form data is well-formed before sending the request. Use schema validation libraries.
// Client-side validation before sending
const data = { name: 'John', age: 30 }
try {
JSON.stringify(data) // Throws if invalid
await fetch('/api/users', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(data)
})
} catch (err) {
console.error('Invalid request data:', err)
}When building APIs, return a descriptive error body with 400 to help clients identify and fix the issue.
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"error": "Bad Request",
"message": "Invalid JSON in request body",
"details": "Expected ',' or '}' after property value at line 3 column 5"
}Related Entries
More from this reference:
401 401 Unauthorized
Authentication is required but was missing or invalid.
403 403 Forbidden
The client is authenticated but does not have permission to access the resource.
404 404 Not Found
The requested resource could not be found on the server.
405 405 Method Not Allowed
The HTTP method used is not allowed for this resource.
Frequently Asked Questions
What is the difference between 400 and 422?
400 is for malformed requests that the server cannot parse (e.g., invalid JSON syntax). 422 (Unprocessable Entity) is for requests with valid syntax but invalid semantics (e.g., missing required fields, invalid enum values).
Should I return 400 for missing required fields?
Many APIs return 400 for missing fields, but 422 Unprocessable Entity or 400 with a detailed validation error body are more semantically correct. The key is consistency — pick one approach and document it clearly.