HTTP 400 Bad Request — causes server-side

Diagnose HTTP 400 responses caused by malformed JSON, failing validation, mismatched content types, and header issues, using server logs and echoes.

beginnerdebugginghttpapivalidation

Symptoms

HTTP 400 Bad Request returned by an API
It appears only for certain clients or payloads
The body is empty or says the request could not be understood

Possible causes

The request body is not valid JSON or is truncated
A required field is missing or fails schema validation
Content-Type does not match the body format
A proxy or WAF rejects the request before it reaches the app

Diagnosis steps

Read the server-side error detail

check application logs for the request id

Interpretation

Frameworks usually log the validation failure or parse error that produced the 400.

Reproduce with a raw client

curl -v -X POST -H 'Content-Type: application/json' -d '{bad}' URL

Interpretation

Bypassing the UI removes client-side formatting assumptions.

Compare Content-Type with the body

Interpretation

Sending form data to a JSON endpoint or vice versa produces a parse failure and a 400.

Root cause

A 400 means the server understood the request line and headers but refused the content: the body failed parsing or validation, or a header contradicted the payload. It is a client-side error class, so the fix usually modifies the request, not the server — but the server must log enough detail to say which field or which parse step failed.

Fix

Validate and fix the request payload against the API contract, ensure Content-Type matches the encoding, and check for truncation on large bodies. On the server, return a structured error naming the offending field so clients can self-correct, and confirm no proxy or WAF is intercepting and rewriting the request before it arrives.

Verify the fix

Resend the corrected request; it returns 200 or the expected code, and the server log no longer records a parse or validation failure for that request id.

Symptoms

The API returns 400 Bad Request. It often occurs only for specific clients, which suggests a formatting or contract mismatch rather than an outage.

Diagnosis

Read server logs and reproduce with curl:

curl -v -X POST https://api.example.com/items \
  -H 'Content-Type: application/json' \
  -d '{"name": "widget"}'

Logging the validation error server-side turns a vague 400 into an actionable field-level message.

Fix

Match the payload to the contract and the content type to the body:

{ "name": "widget", "quantity": 3 }

Return a structured error describing the failing field.

Verification

Resend the corrected request; it succeeds, and the log shows no parse or validation error, confirming the request now matches the API contract.

Where 400s Are Generated

A 400 can originate before your handler runs, in framework body parsing, in schema validation, or at an edge proxy, so where the error is produced changes how you fix it. Enabling request-body logging with a length cap and redaction shows the raw bytes that failed, while a validator that returns field paths turns a generic rejection into a precise contract violation. If the message is empty and no handler logged anything, suspect a proxy or WAF rejecting the request on its own rules, because the application never saw it at all.