400 Bad Request: why servers reject requests and how to fix it

400 Bad Request is the server refusing to process a request because something about it looks broken: a malformed URL, invalid headers, a cookie that’s too big, or a body the application can’t parse. In HTTP terms it’s a client error, but on a website the cause is often the site’s own links, cookies or configuration.

Definition

RFC 9110, section 15.5.1 describes 400 as the server being unable or unwilling to process a request “due to something that is perceived to be a client error,” such as malformed request syntax, invalid message framing or deceptive request routing. It’s the generic 4xx: when nothing more specific fits, servers send 400.

Common causes

• Oversized headers or cookies. Nginx answers “400 Bad Request: Request Header Or Cookie Too Large” when headers exceed large_client_header_buffers; Apache rejects header fields longer than LimitRequestFieldSize (8190 bytes by default).
• Malformed URLs: broken percent-encoding such as a stray % or %zz, raw spaces or control characters, often from links copied out of emails or PDFs.
• Plain HTTP sent to the HTTPS port: Nginx replies “400 The plain HTTP request was sent to HTTPS port.”
• Host header problems, for example Django rejecting host names missing from ALLOWED_HOSTS.
• Invalid API input: malformed JSON or missing required parameters.
• Security rules in a WAF or plugin that answer suspicious requests with 400.

SEO impact

Google’s documentation says all 4xx errors except 429 are handled the same way: Googlebot tells the indexing pipeline the content doesn’t exist, indexed URLs are removed, and any content in the response is ignored. In Search Console these URLs appear as “Blocked due to other 4xx issue.” A 400 on a real page is therefore as damaging as a 404, and harder to notice, because the page may work fine in your own browser.

That’s the classic trap: a 400 triggered by a header or cookie can hit crawlers while you see a normal page, or the reverse. Always test from a clean client, not your logged-in browser.

How to fix a 400

For site owners

1. Check the URL for typos, stray % signs or spaces, and fix the link that produced it.
2. If only you see the error, clear the site’s cookies; a bloated cookie is the most common cause in browsers.
3. Look at your CDN or security plugin logs for blocked requests around the time of the error.

For developers

Raise header limits only if legitimate requests need it, and keep cookies lean:

# Nginx (http or server block)
large_client_header_buffers 4 16k;

# Apache
LimitRequestFieldSize 16380

In APIs, return 400 with a clear message, and use 422 when the syntax is valid but the values fail validation. Don’t return 400 for ordinary page URLs that carry unknown query parameters; ignore the parameters or point a canonical tag at the clean URL instead.

How to check

Paste the affected URLs into the HTTP status checker, which requests them from our servers without your browser’s cookies, and inspect the full response with the HTTP header checker. A typical Nginx response:

HTTP/1.1 400 Bad Request
Server: nginx
Content-Type: text/html
Content-Length: 248
Connection: close

<html>
<head><title>400 Request Header Or Cookie Too Large</title></head>
...

Frequently asked questions