HTTP 400 bad request

What a 400 means

A 400 Bad Request is the server telling the client that the request was malformed: the bytes arrived, but the request line, headers, or body violated the syntax the server could accept. No credentials can unlock it, and unlike 404 the path may exist on disk. As a rule of thumb, the fault is a client-side fault, so the fix starts on the requesting side, even when "the client" is a browser extension or a form nobody touched.

Table of the 4xx that look alike

Common causes

• A header exceeds the request limit, the cookie header is too large, or the host header is missing. A browser with many old cookies will literally produce 400 Bad Request: Request Header Or Cookie Too Large.
• A malformed client, an extension, or a bot sent a request with invalid characters, a broken content length, or an encoding the server rejects.
• The request body breaks the application parser: invalid JSON, a wrong Content-Type that a strict API rejects, or a size above the server limit.
• An old cached copy of a redirect or HTML form is sending a shape the current server rejects, so the failure survives a refresh.
• A WAF or CDN (Cloudflare among them) routes the traffic to a rule set that rejects the computed signature, most visibly on POST paths.
• The app server returns 400 for a "bad header" it recovers from, e.g. an expired timestamp in a signed URL.

The ordered fix list

1. Reproduce the failure. Open DevTools, switch to the Network tab, reload, and save the failing request as a HAR. Look for the response headers: a WAF, the origin, or the app may include the reason in the body or a header.
2. Clear the cookie jar if the page itself 400s. The most common static cause is the session cookie exceeding the header limit. Clear cookies for the domain in browser settings and retry in a private window.
3. Isolate the layer. Run the request outside the browser with curl using the same headers. If curl succeeds, the browser's headers (usually the cookie or user agent) are the difference. If curl fails with 400, the origin or the WAF parses differently.
4. Fix the trigger, not the symptom. If a form is broken, the real cause is usually the form sending a field the new API rejects. Load the previous JSON and fix the payload.
5. Test the proxy path. If Cloudflare returns the 400 edge-side, test an exact URL in low-security or dev mode, or inspect the WAF events for the rejected request.
6. Regress recent changes. A 400 on forms and login after a deploy almost always traces to a changed validator or middleware.

# Minimal repro from the terminal
curl -i -X POST https://example.com/api/order \
  -H "Content-Type: application/json" \
  -d '{"customer": "Sacha"}'
# Compare expected 2xx vs the exactly failing payload

Verify

• The failing URL: request once in a private window, once in curl, and confirm the server keeps returning 400 for the same request.
• The header limit: measure the cookie size. If the browser sends several KB of stale cookies, shrink or purge them.
• The API contract: confirm that the body shape matches the schema, that the fields the validator requires are present, and that the Content-Type matches the encoding.

Prevention

• Keep validation errors informative: a 422-style body that names the field beats a bare 400.
• Cap header and cookie sizes at the edge and the app, so the failure is loud and logged instead of silent.
• Monitor sample 400s by endpoint. A 400 rate that climbs with a deploy is a client regression early signal.

When to involve a professional

If a correct curl still returns 400 and the CDN is in the path, test a request to the origin directly. If the origin accepts it, the WAF signature is the cause, and the vendor logs will show the exact rejected header.