400 Bad Request: What It Means and How to Fix It

A 400 Bad Request means the server received something it could not interpret. Not something it refused — that would be a 403 — and not something it failed to build — that would be a 500. The request itself was malformed, too large, or contradictory, so the server gave up before doing any work.

That points the investigation at the request rather than the server. In a browser, the request is mostly made of the URL, the cookies your browser sends for that site, and any form data. In an API integration, it is the headers and the body your code built. One of those is wrong.

The page might say 400 Bad Request, Bad Request — Request Header Or Cookie Too Large, Your browser sent a request that this server could not understand, or, on Google properties, a bare 400. That’s an error.

Is it just you?

A 400 is very often personal. It depends on what your browser sends, so two people loading the same page can get different results.

• Only you, only in one browser. Almost certainly a cookie or cache problem. See the visitor fixes below.
• Everyone, on one URL. The URL itself is malformed — often a link somewhere that contains a bad character or a broken query string.
• Everyone, on a form or checkout. The form, or the code handling it, is sending something the server rejects.
• Only your code, against an API. The request body, headers, or parameters do not match what the API expects.

Run the page through the website checker. It requests the page with no cookies and no history. If it gets a normal response and you get a 400, the problem lives in your browser, not on the server.

Common causes

Symptom	Likely cause	Fix
“Request Header Or Cookie Too Large”	Cookies for the domain have grown beyond the server’s header limit	Clear cookies for that site; owners should find what is inflating them
400 after clicking one specific link	Malformed URL — illegal characters, bad percent-encoding, a stray %	Fix the link at its source
400 on file upload	File exceeds a size limit, or the form is missing its encoding	Check upload limits and enctype="multipart/form-data"
400 only in one browser	Corrupted cache or cookie	Clear site data, try a private window
400 from an API	Invalid JSON, missing required field, wrong Content-Type	Read the error body — most APIs name the field
400 after login or redirect	A bloated or duplicated session cookie, or a redirect loop adding parameters	Inspect cookies and the redirect chain

Cookies too large

The single most common 400 on real websites. Every request carries every cookie for that domain in its headers. Analytics tools, A/B testing scripts, consent managers, and session handlers each add their own, and a plugin that appends to a cookie on every page view can grow it without limit. Once the header block exceeds the server’s buffer — often 8 KB on nginx and Apache — every request from that browser fails.

Visitor fix: clear cookies for that one site. In Chrome, click the icon to the left of the address bar, then Cookies and site data → Manage on-device site data, and delete the site’s entries.

Owner fix: clearing cookies only fixes one visitor. Find the growing cookie in DevTools → Application → Cookies, identify which script sets it, and fix the script. Raising large_client_header_buffers (nginx) or LimitRequestFieldSize (Apache) buys time but does not solve it.

A malformed URL

Spaces, unescaped % signs, doubled ? characters, or characters the server rejects outright can all produce a 400. These usually come from a hand-typed link, a CMS that did not encode a title properly, or a marketing tool that mangled a tracking parameter.

Fix: find where the broken link lives and correct it there. If it is on your own site, a crawl will surface it — a broken link check flags every internal URL that returns a 4xx, not just 404s.

A form or upload the server cannot accept

Uploads larger than client_max_body_size in nginx produce a 413, but frameworks and proxies sometimes report oversized or malformed bodies as a 400. A form missing enctype="multipart/form-data", a missing CSRF token, or a field the backend validates strictly can all end in a 400.

Fix: reproduce the submission with DevTools open, look at the request payload, and compare it with what the server expects. The server log will normally say which part failed validation.

An API rejecting your request

For developers, a 400 is the API saying “this request does not match my contract”. Good APIs return a JSON body naming the problem — read it before anything else.

The usual suspects:

1. Invalid JSON. A trailing comma or an unescaped quote. Validate the payload before sending.
2. Wrong Content-Type. Sending JSON without Content-Type: application/json, or form data with it.
3. A missing or misnamed field, or a value of the wrong type — a string where a number was expected.
4. Query parameters that conflict, such as two mutually exclusive filters.
5. A stale or malformed token. Some services return 400 rather than 401 for a badly formatted credential.

Quick fixes to try as a visitor

1. Check the URL for typos, extra characters, or a half-pasted address.
2. Clear cookies and cached files for that one site.
3. Open the page in a private window with extensions off.
4. If uploading, try a smaller file.
5. Flush your DNS cache — rarely the cause, but cheap to rule out.

How to confirm the fix

• Request the page with no cookies: curl -sI https://example.com/path. A clean 200 confirms the server is fine.
• Repeat the exact failing action — the form, the upload, or the API call — and confirm a 2xx.
• If you raised a header or body limit, also find what caused the growth, or the 400 will return as the cookie keeps growing.

Why site owners should care

A 400 caused by a runaway cookie only hits returning visitors — the loyal ones who have been to the site many times. New visitors, and you in a fresh test, never see it. That makes it one of the most expensive errors to leave unnoticed: it quietly blocks exactly the people most likely to buy.

SitesRadar’s free plan watches one site from an independent server and emails you when pages start returning 4xx or 5xx codes, alongside broken links, SSL expiry, and DNS changes.

FAQ

What does 400 Bad Request mean? The server could not process the request because it was malformed — a bad URL, oversized headers or cookies, invalid form data, or a body the server could not parse.

How do I fix a 400 Bad Request in Chrome? Clear the cookies and cached data for that one site, check the URL for typos, and try a private window. If it works in private mode, a cookie or extension was the cause.

Is a 400 error a server problem or a client problem? It is classed as a client error: the request was wrong. In practice, the cause is often a site’s own scripts creating oversized cookies, so the owner still has something to fix.

What is the difference between 400 and 404? A 400 means the server could not understand the request. A 404 means it understood perfectly and there was nothing at that address.

Can a 400 error affect SEO? Only if crawlers hit it. Search engines do not send your cookies, so cookie-related 400s rarely affect them, but malformed internal links that return 400 waste crawl budget and should be fixed.