400 - Bad Request
HTTP 400 Bad Request means the server cannot process the request because syntax, framing, or parameters are invalid.
Last reviewed: March 9, 2026|Editorial standard: source-backed technical guidance
What Does Bad Request Mean?
The request is rejected before business logic executes, so the operation never starts until syntax, framing, and parameter contracts are corrected.
Common Causes
- -Nginx or API gateway forwards Content-Type as application/json while client body is form encoded, so backend JSON parser fails at byte 1.
- -Request validation layer rejects missing customerId or malformed UUID in /v1/customers/{id} before controller logic executes.
- -Signature middleware computes canonical query from single-value keys, but duplicated query params arrive and request verification fails.
How to Fix Bad Request
- 1Capture field-level validation details from response payloads and server logs.
- 2Correct request shape, parameter values, and size constraints before retrying.
- 3Add client-side schema validation and boundary checks for repeated invalid payloads.
Step-by-Step Diagnosis for Bad Request
- 1Capture field-level validation details and parser output returned with Bad Request (400).
- 2Compare payload, query parameters, and header shapes with the active API contract.
- 3Validate size, range, and format constraints for request data and metadata fields.
- 4Retest using a minimal valid request, then add optional inputs incrementally.
Syntax and Framing Validation
- -Inspect raw request bytes for parser-breaking syntax or framing defects (example: malformed JSON body, missing multipart boundary, or invalid chunk framing).
- -Verify Content-Type, Content-Length, and transfer framing are consistent across client, proxy, and origin (example: declared JSON with non-JSON payload).
Field Contract Verification
- -Trace field-level violations to concrete API contract rules (example:
limitout of allowed range or requiredcustomerIdmissing). - -Replay with a minimal valid payload and reintroduce optional fields one by one to isolate the failing parameter path.
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 400 Bad Request
# {"error":"Bad Request","code":"400"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 400) {
console.error('Handle 400 Bad Request');
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 400:
print('Handle 400 Bad Request')How to Verify the Fix
- -Resubmit the request and confirm 400 no longer appears for valid input sets.
- -Run boundary and malformed-input tests to verify parser and validator behavior.
- -Confirm request serialization remains contract-compliant across all supported clients.
How to Prevent Recurrence
- -Enforce schema validation and input linting at client and gateway boundaries.
- -Add contract tests for parser edge cases, header limits, and body-size thresholds.
- -Track contract changes and version migrations to prevent request-shape drift.
Pro Tip
- -persist a sanitized copy of every 400 response with field-violation details and replay those payloads in CI as permanent regression tests.
Decision Support
Compare Guide
HTTP 400 vs 422: Bad Request vs Unprocessable Content
Fix API payload issues faster by using 400 for malformed syntax and 422 for semantic validation failures, so clients correct format before business rules.
Playbook
Validation Failure Playbook (400 / 422 / INVALID_ARGUMENT)
Use this playbook to separate malformed-request failures from semantic validation failures, then fix request contracts without broad server-side bypasses.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.