HTTP 400 Bad Request
When your server returns HTTP 400 Bad Request, it is telling the client: I cannot even parse what you sent me. The request itself is broken before any business logic runs. Common symptoms:
- An API client getting 400 on every request after a code change
- A form submission that worked yesterday failing today with 400
- A curl command returning 400 when testing an endpoint
The first thing to check is always the raw request — use curl -v or inspect the actual bytes sent. JSON syntax errors, wrong Content-Type headers, URL encoding issues, and truncated payloads are the most frequent causes. If the request looks correct, check whether the server recently updated its schema validation logic.
Quick reference
| Code | 400 |
|---|---|
| Name | Bad Request |
| Category | 4xx client errors |
| Specification | RFC 9110 |
| IANA status | Assigned |
| When to use | Return 400 when the request is syntactically invalid or unparseable. Use 422 when the request is syntactically valid but semantically invalid (valid JSON that violates business rules). Use 401 for missing/invalid authentication, 403 for insufficient permissions, 404 for unknown resources. |
| Client behavior | Do not retry automatically — the same malformed request will receive the same 400. Fix the request format and retry. API clients should surface the error to the developer with the response body details. |
| Caching | Not cached. Error responses are generally not stored. |
Common causes
- Invalid JSON in request body
- Missing required query parameters
- Malformed URL or headers
- Type mismatch in API payload
- Encoding issues
How to fix it
- Validate request body against the API schema before sending
- Check required parameters are present
- Ensure Content-Type header matches the body format
- Use a linter or schema validator during development
Example exchange
GET /example HTTP/1.1 Host: errorlookup.com HTTP/1.1 400 Bad Request
When you see this in production
Monitor 400 rates per API endpoint. A spike in 400s on a specific endpoint after a deployment usually means:
- Client code is sending a field in the wrong format
- A required field was added server-side but the client has not been updated
- Content-Type header is wrong (sending JSON with form encoding, or vice versa)
Log the request body (redacted as needed) alongside 400 responses to accelerate debugging.
What developers usually do next
- Debugging a 400:
- 1. Check the raw request body with curl -v or a proxy like mitmproxy
- 2. Validate JSON syntax with jq or jsonlint
- 3. Confirm the Content-Type header matches the body format
- 4. Check that all required fields are present and correctly named
- 5. Read the error response body — good APIs include field-level validation details
- 6. If using an SDK, check for SDK version mismatches that may generate invalid payloads
When NOT to use this code
Do not use 400 for: authentication failures (use 401), authorization failures (use 403), resources that do not exist (use 404), or semantic validation failures where the structure is valid (use 422). Reserve 400 for genuinely malformed, unparseable requests.
Related status codes
HTTP 401 Unauthorized · HTTP 403 Forbidden · HTTP 404 Not Found · HTTP 422 Unprocessable Content
Comparisons
HTTP 400 vs 403 · HTTP 400 vs 404 · HTTP 400 vs 409 · HTTP 400 vs 422 · HTTP 400 vs 431
Frequently asked questions
What is the difference between 400 and 422?
400 means the request is syntactically malformed. 422 Unprocessable Entity means the request is syntactically valid but semantically invalid — for example, a valid JSON payload that violates business rules.
Standards reference
This definition is derived from the IANA HTTP Status Code Registry and RFC 9110. Human-readable operational guidance by ErrorLookup. · HTTP 400 quick reference →