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

A 400 means the server could not understand the request well enough to process it, and it blames the client for that. Unlike a 404 or 500, the problem is in what was sent: a malformed URL, a broken header, an oversized cookie, or a body that does not parse. The HTTP 400 reference has the formal definition.

You may see "400 Bad Request", "Bad Request - Invalid URL", "Bad Request - Request Header or Cookie Too Large", or a bare JSON error from an API. The wording depends on who answered: nginx, Apache, IIS, a CDN or the application itself.

If you are a visitor

Work through these in order. Each takes under a minute.

1. Check the URL. A stray space, a pasted % that is not followed by two hex digits, or a double // in a query can trigger a 400. Retype the address rather than editing the old one.
2. Delete the cookies for that site only. The classic cause is a cookie that grew too large or got corrupted. Clearing it fixes "Request Header Or Cookie Too Large" almost every time. See HTTP 431 for the same problem under a different status.
3. Try a private window. If the page loads, an extension or cookie is the cause.
4. Clear the cache if the site recently changed and an old redirect or script is being replayed.
5. Upload problems? A file name with unusual characters, or an upload that was interrupted, can produce a 400. Rename the file and retry.

If every browser and device returns 400, the fault is on the site. Tell the owner the exact URL and the time.

If you own the site

1. Oversized or corrupt cookies and headers

Marketing tags, A/B tools and sessions across subdomains pile up cookies on the parent domain. The browser then sends a Cookie header larger than the server's buffer. In nginx the log line looks like this:

client sent too long header line

Raise the buffers only if you must, and prefer trimming cookies:

large_client_header_buffers 4 16k;

Apache's equivalents are LimitRequestFieldSize (default 8190 bytes) and LimitRequestLine. Use the Cookie Checker to see what you set, and the HTTP Header Checker to inspect the response.

2. Invalid characters or encoding in the URL

Servers reject raw spaces, unescaped control characters and bad percent-encoding. Common sources are links built by string concatenation and redirects that copy a query string unescaped. Break an address apart with the URL Parser and test encoding with the URL Encoder/Decoder. In code, use the platform's encoder (encodeURIComponent in JavaScript, urllib.parse.quote in Python) instead of manual replacement.

3. Malformed request body

APIs return 400 when JSON is invalid, a Content-Type does not match the body, or a required field is missing. Reproduce it with curl and read the body of the error:

curl -i -X POST https://api.example.com/items \
  -H "Content-Type: application/json" \
  -d '{"name": "test"}'

Paste the payload into the JSON Validator to catch trailing commas and unescaped quotes. If the failure is about the declared type rather than the content, see HTTP 415. If the JSON is valid but fails business rules, many frameworks use 422 instead.

4. Host header and protocol mismatches

A request with a missing or unknown Host header, HTTP/1.1 sent without it, or a TLS connection sent to a plain-HTTP port produces a 400 on many servers. nginx reports "The plain HTTP request was sent to HTTPS port" when you hit an HTTPS listener over HTTP. Check that your load balancer forwards to the right port and protocol.

5. Proxy, CDN or WAF rules

A web application firewall may answer 400 for requests that look like an attack, and some CDNs reject malformed headers before they reach you. Compare a request direct to the origin with one through the CDN. If only the CDN path fails, check its firewall logs and header-size limits.

Find the cause quickly

1. Reproduce with curl -v and save the full response.
2. Read the origin's error log at the moment of the request. nginx logs client-side problems at info or error level; Apache logs them in error_log.
3. Remove cookies, then remove optional headers, then shrink the body until it works. That isolates the culprit.

Run the failing URL through the HTTP Status Checker to confirm what an unauthenticated outside client sees.

Next steps

• Look up the HTTP 400 reference and related codes.
• Inspect a failing response with the HTTP Header Checker.
• Read Fix 500 Internal Server Error if the error changes after you fix the request.
• Add an Uptime Monitor for the affected endpoint so regressions page you first.

FAQ

Is a 400 error my fault or the website's?

Usually the request is at fault: a bad URL, cookie or payload. But a site can cause it by setting huge cookies itself or by misconfiguring a proxy, so check both sides.

Why does clearing cookies fix a 400?

A cookie that is too big or corrupted makes the request header invalid or larger than the server accepts. Removing it sends a small, clean header.

Should an API return 400 or 422?

400 fits requests that cannot be parsed. 422 fits well-formed requests that fail validation. Pick one convention and document it.

Can search engines index a page that returns 400?

No. Crawlers treat it as an error and drop or skip the URL until it returns a 200.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.