How to Fix 400 Bad Request Error
A 400 Bad Request is an HTTP status code that means the server received your request but considered it malformed or invalid, so it refused to process it. Unlike 500-level errors, which point at a broken server, a 400 is a client-side problem: something in the request — the URL, the headers, the cookies, or the body — does not match what the server expects. The generic message Chrome shows is simply “400 Bad Request”, and the server's response body often adds little detail, which is exactly why the error feels so frustrating to debug.
The good news is that “client-side” does not always mean “your fault”. A 400 can be triggered by a corrupted cookie, a URL you pasted from a chat app that mangled its characters, a stale DNS entry pointing at the wrong host, or a browser extension rewriting headers behind your back. This guide covers the six root causes behind almost every 400 Bad Request, with concrete commands you can run to confirm each one and the exact fix that resolves it.
What is 400 Bad Request?
The HTTP 400 status code is defined in RFC 9110 as the response a server returns when it “cannot or will not process the request due to something that is perceived to be a client error”. The server reads the request line, the headers, and (if present) the body, and at some point decides the request is not well-formed enough to act on. Crucially, the server sends 400 instead of trying to guess what you meant — it does not auto-correct a bad URL or silently drop an oversized cookie.
Because the definition is broad, the visible cause varies. In a browser, the most common trigger is an oversized or corrupted cookie that pushes the request header past the server's limit (Nginx's default large_client_header_buffers, for example, rejects a request line plus headers larger than 8K). In an API client, a 400 usually means a missing required parameter, a malformed JSON body, or a wrong Content-Type. On a site you do not control, a 400 can even be caused by a DNS-level redirect that lands your request on a host that was never meant to receive it.
The practical takeaway: a 400 tells you the request never reached your application code. The web server or framework rejected it during parsing, before any handler ran. That narrows the search to the things the server evaluates first — the URL, the headers, the cookies, and the body size.
Common Causes
Before diving into the step-by-step fix, use this table to quickly match your situation to its root cause and the step that resolves it.
| Cause | Where It Happens | Fix |
|---|---|---|
| Corrupted or oversized cookies exceed the server header limit | Client browser (Nginx large_client_header_buffers) |
Clear cookies for the domain; test in incognito (Step 1) |
| URL contains syntax errors, bad encoding, or trailing junk | Address bar, pasted links | Re-check the URL; fix malformed characters (Step 2) |
| Stale DNS cache resolves the domain to the wrong host | OS / browser DNS cache | Flush DNS cache (Step 3) |
| Request body or headers exceed server size limits | File uploads, large JSON, custom headers | Reduce size; raise server limits (Step 4) |
| Browser extension rewrites or blocks request headers | Client browser extensions | Disable extensions; test in a clean profile (Step 5) |
| Malformed request sent by a script or API client | curl, fetch, Postman | Reproduce with curl and inspect headers (Step 6) |
Step-by-Step Fix Guide
Step 1: Clear browser cookies and cache
The single most common cause of a 400 in a browser is a cookie that has grown too large or become corrupted. Cookies are sent with every request to their domain, so a bloated cookie inflates the request header on every single page load. Once the header crosses the server's limit, every request is rejected with 400 — which looks like the whole site is down when really only your browser is broken.
In Chrome, open DevTools (F12), go to Application → Cookies, select the domain, and delete every entry. Also clear the cache under Application → Clear storage. Then reload the URL in a fresh incognito window. If the 400 disappears, the cause was a cached cookie on your machine — no server change is needed, although you may want to find out which cookie caused it so other visitors are not affected.
Step 2: Check the URL for syntax errors
The request line is the first thing a server parses, so a malformed URL is an instant 400. Look for typos, double slashes, stray spaces, unencoded special characters, or junk that got appended when you copied a link from a chat app or PDF. A common offender is a non-breaking space or a smart quote that replaced a normal character during copy-paste.
Percent-encode any reserved characters. Spaces become %20, a literal # in a path becomes %23 (otherwise the server treats it as a fragment), and non-ASCII characters must be UTF-8 encoded then percent-encoded. After fixing, reload. If the URL was the culprit, the 400 vanishes immediately.
Step 3: Flush your DNS cache
If only you see the 400 while everyone else loads the site fine, a stale DNS entry is a strong suspect. Your OS and browser both cache DNS answers, and if the domain recently changed IP addresses (a migration, a CDN switch, or a failover), your cache may still point at an old host that rejects your request as malformed because it does not serve that hostname at all.
Flush the cache and retry. On Windows:
ipconfig /flushdnsOn macOS (pick the interface, usually Wi-Fi):
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponderOn Linux with systemd-resolved:
sudo resolvectl flush-cachesIn Chrome, visit chrome://net-internals/#dns and click Clear host cache. Then reload the page. If the 400 cleared, a stale DNS record was sending your request to the wrong server.
Step 4: Check request size and headers
Servers cap the size of a request for safety. Nginx's large_client_header_buffers limits the request line plus headers (default 8K), client_max_body_size limits the body (default 1M), and Apache's LimitRequestFieldSize and LimitRequestBody do the same. Exceed any of them and the server returns 400 (or 413 for an oversized body) before your application ever sees the data.
If you control the server, raise the limit to fit legitimate traffic. In Nginx, for example:
server {
large_client_header_buffers 4 16k;
client_max_body_size 10m;
}If you do not control the server, shrink the request. Split a large JSON payload, remove unused custom headers, or compress the body with gzip and set Content-Encoding: gzip. The goal is to keep the request under the server's configured ceiling.
Step 5: Disable browser extensions
Privacy tools, ad blockers, and developer extensions can intercept outgoing requests and rewrite or strip headers. An extension that removes Referer, mangles Cookie, or injects a malformed User-Agent can turn a valid request into one the server rejects with 400.
The fastest test is a clean profile. Open an incognito window with extensions disabled (or create a fresh browser profile with no extensions) and load the URL. If it works there but fails in your normal profile, bisect your extensions: disable half, test, and repeat until you find the one rewriting the request. Once identified, adjust its settings for that domain or remove it.
Step 6: Test the request with curl
When the cause is not obvious, reproduce the request outside the browser so you can see exactly what is sent and returned. curl -v prints both the outgoing request and the incoming response, including every header. This lets you compare a failing request against a working one and pinpoint whether the 400 comes from the URL, a header, a cookie, or the body.
curl -v https://example.com/Read the response headers and body. A server that explains the 400 (for example, “Cookie too large” or “Invalid parameter”) tells you exactly what to fix. If curl succeeds where the browser failed, the problem is in your browser's cookies or extensions — return to Step 1 or Step 5.
HTTP Diagnostic Commands
These curl one-liners cover the diagnostics you need while debugging a 400. Start with the headers-only request, then get more specific depending on what you suspect.
# 1. Fetch only the response headers and status line
curl -I https://example.com/
# 2. Verbose: print the full request AND response (best for 400 debugging)
curl -v https://example.com/
# 3. Print just the HTTP status code
curl -o /dev/null -s -w "%{http_code}\n" https://example.com/
# 4. Send a custom header to test how the server reacts
curl -H "X-Test-Header: value" https://example.com/
# 5. Send a JSON body via POST (common API 400 trigger)
curl -X POST \
-H "Content-Type: application/json" \
-d '{"key":"value"}' \
https://example.com/api
# 6. Include a cookie explicitly to reproduce a cookie-driven 400
curl -v -H "Cookie: session=abc123" https://example.com/Command 2 (curl -v) is the workhorse: it shows the request line, every request header, the response status, and every response header, so you can see the exact moment the server decides the request is bad. Commands 5 and 6 are especially useful for API and cookie-related 400s, because they let you vary a single input at a time.
Quick Reference Table
400 is often confused with 401, 403, and 404 because all four are 4xx client errors. The difference is what the server is complaining about: the request's shape, your identity, your permission, or the resource's existence.
| Code | Name | Meaning | Who Is At Fault | Typical Cause |
|---|---|---|---|---|
| 400 | Bad Request | Request is malformed or invalid | Client | Bad URL, oversized cookie, malformed body |
| 401 | Unauthorized | Authentication is required | Client (not logged in) | Missing or invalid credentials |
| 403 | Forbidden | Server refuses to authorize the request | Client (or policy) | No permission, IP blocked, hotlink protection |
| 404 | Not Found | Resource does not exist | Client (wrong URL) | Typo, deleted page, wrong path |
A quick way to tell them apart: if the server understood the request but you are not allowed in, that is 401 or 403. If the server understood the request but the thing is not there, that is 404. If the server could not even understand the request, that is 400. So always confirm the 400 is really about the request's shape before chasing permissions or missing pages.
FAQ
What is the difference between 400 and 404?
A 400 Bad Request means the server could not parse the request itself — the URL, headers, cookies, or body were malformed. A 404 Not Found means the request was perfectly valid and well-formed, but the resource it asked for does not exist on the server. In short: 400 is “I cannot understand this request”, 404 is “I understood it, but that thing is not here”.
Why does 400 Bad Request happen only in my browser?
Because the cause lives in your browser, not on the server. A corrupted or oversized cookie, a cached redirect, or an extension that rewrites headers will make only your browser send a malformed request. Test in an incognito window or a clean profile: if the 400 disappears, clear the domain's cookies and cache (Step 1) or disable extensions (Step 5).
Can a cookie really cause a 400 Bad Request?
Yes, and it is the most common browser-side cause. Cookies are sent as part of the request header on every request to their domain. If a cookie grows very large (often because a tracking or session script keeps appending to it) or becomes corrupted, the total request header can exceed the server's limit — Nginx's large_client_header_buffers by default — and the server returns 400. Deleting that cookie fixes it instantly.
How do I fix a 400 Bad Request from an API I am calling?
Reproduce the call with curl -v so you can see the exact request and response. Check that the URL is correct, that Content-Type matches the body (e.g. application/json for a JSON payload), that all required parameters are present, and that the body is valid JSON. The API's 400 response usually names the offending field — read the response body carefully and correct that one input.
Conclusion
A 400 Bad Request always means the server rejected the request before doing any real work, which is why the fix is almost always on the client side. Work through the six steps in order: clear bloated cookies and cache, fix URL syntax errors, flush a stale DNS cache, trim oversized request headers and bodies, disable header-rewriting extensions, and reproduce the request with curl -v to see exactly what is wrong. In the vast majority of cases the culprit is a single oversized cookie or a mangled URL, and once you remove it the 400 disappears for good. If curl succeeds but your browser still fails, you know the problem is local — and Steps 1 and 5 will find it.