400 Status Code: Decoding the Bad Request Error

Aug 07, 2026 · HTTP Status Codes

The support ticket read: "Site completely broken, shows 400 Bad Request — but only for me, on one computer, in one browser." Tickets like this used to eat afternoons until I learned the pattern: it's almost always cookies. An A/B testing script had been appending data to a cookie on every page view for weeks, the cookie crossed the server's header size limit, and that browser could no longer send a request the server would accept. Cleared the cookies, site "fixed" — then we capped the script so it couldn't happen again.

That's the character of the 400 status code: the server isn't broken, your page isn't missing — the request itself was malformed enough that the server refused to process it.

What a 400 status code actually blames

Every 4xx code assigns fault to the client, and 400 is the generic catch-all: "something about this request is wrong, and I won't guess what you meant." The server parsed enough to reply, but a syntax problem — in the URL, the headers, the cookies, or the body — stopped it from going further. Contrast that with a 500, where the request was fine and the server tripped over its own code. When you're triaging, that's the first fork in the road: 400 means inspect the request, 500 means inspect the server.

The usual suspects

Isolating the broken piece

The technique that solves most 400s is subtraction: reproduce the failure with the smallest possible request, then add pieces back until it breaks. Start from a bare request:

curl -v "https://example.com/path" 2>&1 | grep -E "^(>|<)"

The -v output shows every header sent (lines starting with >) and received (<). If this minimal request succeeds where the browser fails, the problem lives in something the browser adds — cookies, auth headers, a user-agent-triggered WAF rule. Copy the browser's exact request as a curl command (DevTools → Network → right-click the request → Copy as cURL) and delete headers one at a time until the 400 disappears. The last thing you removed is your culprit.

If even the minimal request fails, the URL itself is suspect. Watch for characters that need percent-encoding: spaces, quotes, curly braces, pipes, and anything a CMS or email client might have mangled when the link was pasted.

Server-side knobs worth knowing

Sometimes the request is legitimate and the server's limits are just too tight for it. On nginx, oversized cookies and headers hit large_client_header_buffers — the default allows 8k per header line, and a big SSO token plus accumulated cookies can exceed it. The error log will say "client sent too long header line." Raising it looks like:

large_client_header_buffers 4 16k;

Apache's equivalent is LimitRequestFieldSize. Raise these deliberately, not reflexively — a 16k limit is reasonable; a 64k limit usually means you're papering over a cookie leak that will keep growing. Fix the thing writing the giant cookie.

One more server-flavored 400 worth recognizing on sight: nginx's "The plain HTTP request was sent to HTTPS port" message. It appears when something speaks unencrypted HTTP to port 443 — a health check probing the wrong scheme, a proxy misconfigured to forward http:// upstream, or a hardcoded internal URL that never got updated after the TLS migration. The request is syntactically fine; it's just knocking on a door that only speaks TLS. Fix the caller's scheme, not the server.

400s and search engines

Googlebot sends clean, well-formed requests, so a healthy page should never serve it a 400. When Search Console or a crawl report shows 400s, it almost always means malformed URLs are being linked somewhere — a template generating hrefs with unencoded characters, query strings truncated by a newsletter tool, or a migration that mangled paths. Each of those is a broken link shipping visitors and crawlers into a wall. The pages serving 400 won't be indexed, and any link equity flowing into those URLs is discarded.

Finding them is a two-part job: crawl your site to list every URL answering 400, then find where each broken URL is linked from — the crawl's "found on" data or a log search does it — and fix the link at its source. Correcting the href in one template often clears hundreds of 400s at once.

Keeping Bad Requests rare

Three habits prevent most recurrences. Encode URLs at generation time — every templating language has a URL-encoding filter; use it on any dynamic segment. Put a size budget on cookies — if a script needs more than a couple of kilobytes of client-side state, it should be in localStorage, not riding along on every HTTP request. And when a 400 does appear, log the full offending request server-side (nginx's $request plus header sizes) so the next investigation starts with evidence instead of a vague ticket.