400 Bad Request

The short version: In most cases the fix lives on your end. Clear the cookies and cache for that one website, retype the URL to strip out any typos or stray characters, and load the page in an incognito window. If that does it, the culprit was a stale or oversized cookie.

Key takeaways

• 400 Bad Request means the server could not parse the request itself: malformed syntax, invalid message framing, or, per RFC 9110, anything the server perceives as a client error. It stops before checking identity, permission, or whether the page exists.
• The word server is misleading here. The broken request almost always starts on your side, and the two usual triggers are a corrupted or oversized cookie and a URL with a typo or an illegal character.
• One variant in particular, 400 Bad Request: Request Header Or Cookie Too Large, shows up on servers like nginx when the request headers blow past the buffer, 8 KB by default. For a visitor, clearing that website's cookies almost always fixes it.
• Since the cause rides along with your browser or the request, the same page usually loads in an incognito window or on another device. That is the fastest way to prove the problem is local rather than the website being down.
• A 400 is a genuine HTTP response, so the server still looks healthy from outside. An up-or-down ping will report the website up while a broken API or form endpoint quietly keeps rejecting requests.

Error type

HTTP 4xx client error

Whose side

Usually your side; sometimes the website

Fix difficulty

Easy

Common cause

The server could not parse the request

What does 400 Bad Request mean?

A 400 Bad Request is an HTTP status code in the 4xx family, which puts the problem on the request side rather than down to a crash on the server. Per the HTTP specification and MDN, the server returns a 400 when it refuses to process the request because of something it treats as a client error, typically malformed request syntax, invalid message framing, or a deceptive request route. The server bails out at the parsing stage. It never reaches the logic that would check authentication, permissions, or whether the page even exists, because the request was unreadable before any of that mattered. Send the same request again unchanged and it fails again with the same 400.

The word server in the message is a red herring. The broken request usually comes from the visitor's side, and two triggers account for most cases: a corrupted or oversized cookie sitting in your browser, and a URL carrying a typo or an illegal character. Less often the blame falls on a stale local DNS entry, a browser extension that rewrites the request, or an upload bigger than the server will take. And because the cause travels with your browser or the request itself, the same page often loads fine in an incognito window or on another device, which is the quickest way to tell whether the problem is local or the website is actually down.

400

HTTP status code

4xx

Client-side error class

8 KB

Default nginx header buffer size

How the 400 Bad Request error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

400

Bad Request

Your browser sent a request that this server could not understand.

• 400 Bad Request
• HTTP Error 400
• Bad Request
• Error 400
• 400 Bad Request: Request Header Or Cookie Too Large
• 400 Bad Request nginx

400 vs 401, 403 and 404

All four are 4xx client errors, but each one fails at a different point in handling the request.

400 vs 401, 403, 404 and 429 at a glance

All five are 4xx client errors, but each fails at a different stage of handling the request, points at a different person, and has a different typical cause.

What causes 400 Bad Request?

• Oversized or corrupted cookies for that website. This is the single most common cause: a bloated or stale cookie makes the request header too large or unreadable, and the server throws it out (often shown as 400 Bad Request: Request Header Or Cookie Too Large).
• A request header that overruns the server's buffer limit even without huge cookies, say when a proxy, SSO, or auth layer keeps stacking on headers until they pass the default size.
• A malformed or mistyped URL: a typo, a stray space, or a missing = or & in a query string the server cannot parse.
• Invalid or badly encoded characters in the URL. Think a literal {, or broken percent-encoding like %%20 where %20 was meant.
• A stale or corrupted local DNS cache that no longer lines up with the website's current records, so the request leaves malformed or aimed at the wrong place.
• A browser extension, ad blocker, or security tool that rewrites the request headers, cookies, or URL before it ever leaves the browser.
• An upload or POST body bigger than the server accepts, or a malformed request body such as invalid JSON sent to an API, which the server cannot read.

How to find the cause fast

1. Pin down the scope first. Does every website throw a 400, or only this one URL? A single website points to its cookies or a bad link; errors everywhere point to your browser, an extension, or your DNS cache.
2. Read the URL slowly, looking for typos, stray spaces, and characters that should have been encoded. Then follow a known-good link to the same website instead of one you typed by hand.
3. Open the page in an incognito or private window. It runs without your cookies and most of your extensions, so if the page loads there, a stored cookie or an add-on on your normal profile is to blame.
4. Own the endpoint? Reproduce the error with curl -v or the browser network panel to see the exact request line, headers, and body the server is rejecting.

Terminal

curl -sI 'https://example.com/search?q=%'HTTP/1.1 400 Bad Request# the % is an invalid URL escape the server rejected

How 400 Bad Request looks from the outside

A 400 is a genuine HTTP response, so from outside the server still looks fine: the connection opens, TLS completes, and a reply comes back fast, just carrying the wrong status code. A plain up-or-down ping will call the website up while a broken endpoint keeps turning requests away. To catch it, check the actual status code on the URL that matters, not just whether the host answers. One more thing worth knowing: a 400 usually reflects the specific request that was sent, so an API or form can 400 on malformed input while the rest of the website runs perfectly.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 400 Bad Request

If you are a visitor

1. Clear the cookies and cache for that specific website. A corrupted or oversized cookie is the most common trigger, and you rarely need to wipe data for every website to fix it.
2. Read the URL again for typos, extra spaces, and missing or illegal characters. Retype it, or follow a known-good link instead of a pasted one.
3. Open the page in an incognito or private window to test it free of your cookies and extensions.
4. Turn off browser extensions, ad blockers and security add-ons especially, then switch them back on one at a time until the one altering the request shows itself.
5. Flush your DNS cache (ipconfig /flushdns on Windows, the dscacheutil command on macOS) in case a stale record is breaking the request.
6. Restart the browser, or hop to a different browser or device, to rule out a corrupted session on your current one.
7. Were you uploading a file? Try a smaller one. A file over the website's size limit can come back as a 400.
8. If it still fails on every browser and device, the fault sits on the website's side. Wait and retry later, or get in touch with the website owner.

If you run the website

1. Seeing Request Header Or Cookie Too Large? Raise the header and cookie buffer limits: on nginx, bump large_client_header_buffers and client_header_buffer_size, then reload, and trim oversized cookies at the source so headers stay small.
2. Validate and sanitize incoming requests so a malformed URL, header, or body returns a clear, deliberate response rather than a generic 400. Log the rejected requests too, so you can see exactly what is being sent.
3. For any API or form that is 400ing, check the request format: confirm the method, the content type, the required fields, and that the body (JSON, for instance) is well-formed and correctly encoded.
4. Audit your WAF, CDN, and reverse-proxy rules. An edge layer can reject or rewrite a request and hand back a 400 long before it reaches your origin.
5. Make sure your upload and request-size limits are sane (body and field size in nginx or PHP, for example), so legitimate uploads do not get bounced as bad requests.

Still not fixed? Next steps

• Reproduce the exact request with curl -v so you can see the request line, every header, and the body the server is rejecting. A huge Cookie line or a mangled header tends to stand out immediately.
• When only an API or form 400s, check the payload against the endpoint's spec: the method, the Content-Type, the required fields, and whether any JSON body is well-formed and correctly encoded. The rest of the website staying healthy is a strong hint that one specific request is the problem.
• Seeing Request Header Or Cookie Too Large on the server? Raise large_client_header_buffers and client_header_buffer_size in nginx, then trim the oversized cookies at the source. Keeping the headers small beats simply widening the buffer to swallow them.
• Look at whether a WAF, CDN, or reverse proxy is rewriting or rejecting the request at the edge and handing back a 400 before it ever reaches your origin. Bypass the edge to find out whether the origin itself would have accepted it.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Raise nginx header and cookie buffer limits

# in the http block of nginx.conf, then reload nginx
http {
  client_header_buffer_size   4k;
  large_client_header_buffers 4 16k;
}
# default is 8k; raising it fixes "Request Header Or Cookie Too Large"

Inspect the exact request your client is sending

# -v prints the request line, headers, and the status you get back
curl -v https://example.com/path
# watch for malformed headers, a huge Cookie line, or a bad URL

Flush the local DNS cache so a stale record cannot break the request

# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

How to prevent 400 Bad Request

A 400 usually clears with a cookie or cache reset, but the picture changes when your own API or app starts rejecting valid requests: now every client hits the wall at the same time. Pulsetic checks your website and endpoints from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, Telegram, or webhook the moment a URL stops returning what you expect. It gauges availability from the outside, not from your server's internals.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.