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

What Is a 400 Bad Request Error?

400 Bad Request is an HTTP status code that means the server got your request but won't process it because something about the request itself looks wrong. The HTTP standard defines it as the server being unable or unwilling to process a request "due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)" (RFC 9110 §15.5.1).

Unlike a 500 error, which means the server broke, a 400 points the finger at the request: the URL, the headers, the cookies or the data your browser or app sent. The website is usually working fine for everyone else.

That's good news for visitors, because the fix is often on your side and takes a minute: a mistyped or damaged link, or cookies that have grown too big for the server.

What a 400 Error Looks Like

The message depends on the server software, and the extra text is often the best clue to the cause:

What Causes a 400 Bad Request?

• A malformed URL. A stray % sign, a space, a character that should have been encoded, or a link that was cut off or pasted twice.
• Corrupted or oversized cookies. Sites that set many cookies (logins, A/B tests, analytics) can push the Cookie header past the server's limit. A cookie damaged during an update can also be rejected.
• Too-large request headers. Besides cookies, long authentication tokens or headers added by extensions and proxies add up.
• Invalid data sent to an API. Missing required fields, malformed JSON, or the wrong Content-Type header.
• HTTP sent to an HTTPS port. Common behind load balancers and reverse proxies.
• A file that's too large. Many servers reply 413 Content Too Large, but some apps and frameworks return 400 instead.

Fix 1: Check the URL

Look closely at the address bar. Problems to watch for:

• A % that isn't followed by two hexadecimal characters (%20 is fine, %2 or %zz isn't).
• Spaces, { }, |, \ or other unusual characters, especially in links copied from emails, PDFs or chat apps.
• A link that was pasted twice (https://example.com/https://example.com/...) or cut off partway.
• A very long URL with tracking parameters. Delete everything from the ? onwards and try again.

If you followed a link from another site, go to the site's homepage and navigate to the page from there instead.

Fix 2: Clear Cookies for That One Site

This is the fix for messages that mention cookies or headers being "too large" or "too long", and it's worth trying for any 400 on a site you've used before. You don't need to wipe cookies for every site, just this one:

• Chrome: click View site information at the left of the address bar → Cookies and site data → Manage on-device site data → delete the site's data, then reload.
• Edge: Settings → Privacy, search, and services → Cookies → See all cookies and site data → search for the site → delete it.
• Firefox: click the padlock → Clear cookies and site data…
• Safari (Mac): Safari → Settings → Privacy → Manage Website Data… → search for the site → Remove.
• iPhone: Settings → Apps → Safari → Advanced → Website Data → swipe left on the site to delete.

Fix 3: Try Incognito, Then Clear the Cache

Open the page in an Incognito/Private window (Ctrl + Shift + N in Chrome and Edge, Ctrl + Shift + P in Firefox, Cmd + Shift + N in Safari). Private windows start with no cookies, no cached files and usually no extensions, so if the page works there, Fix 2, Fix 4 or clearing cached files (Ctrl + Shift + Delete → Cached images and files) will solve it permanently.

If Incognito also fails, your cookies, cache and extensions aren't the cause: check the URL again, turn off any VPN or proxy, and as a last step flush your DNS cache. DNS is rarely the cause of a 400, but after a site moves servers an outdated address can land you on a server that rejects your request.

Fix 4: Disable Extensions and Check File Sizes

Extensions that modify requests, such as privacy tools, header editors, coupon finders and some ad blockers, can add or change headers in ways a server rejects. Disable them all, reload, then turn them back on one at a time to find the culprit.

If the error appears when uploading, try a smaller file. Compress images or split large files. That tells you whether the server is rejecting the size, even if it reports it as a 400 instead of 413.

For Website Owners: Finding the Cause of 400 Errors

If users report 400 errors on your site, start with the exact message they see and your server logs. nginx logs the reason at the info level; Apache logs oversized headers at info but malformed URLs and headers only at debug, so raise the error log level temporarily if you don't see it (error_log … info; in nginx, LogLevel debug in Apache). The access log shows which URLs return 400. DNS Robot's HTTP Header Checker shows the status code, the server software and each cookie a first visit sets, with its size; cookies that scripts add later, such as analytics, only show in your browser's DevTools (Application → Cookies).

# Which requests get 400? (nginx combined log format)
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# The reasons nginx logged (needs error_log ... info;)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

"Request Header Or Cookie Too Large"

nginx reads request headers into buffers set by large_client_header_buffers, by default 4 buffers of 8 KB. A header field that doesn't fit in one buffer, usually the Cookie header, gets this 400, and so do headers that need more than all 4 buffers together (about 32 KB); a request line (the URL) that's too long gets 414 instead (nginx). Apache's equivalent limit is LimitRequestFieldSize, 8,190 bytes by default (Apache).

We tested it on nginx.org itself (nginx 1.31.3) on 27 October 2026: a request with a 7,000-byte cookie got the normal page, and one with a 9,000-byte cookie got exactly this:

<html>
<head><title>400 Request Header Or Cookie Too Large</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>Request Header Or Cookie Too Large</center>
<hr><center>nginx/1.31.3</center>
</body>
</html>

The proper fix is to send less: remove cookies you no longer need, keep session cookies small, and scope cookies to the paths and subdomains that use them. If you really need bigger headers, for example for large single sign-on tokens, raise the limit:

# nginx: http block or the default server (other server blocks can be ignored)
large_client_header_buffers 4 16k;

# Apache equivalent: main config or the first-listed virtual host
# LimitRequestFieldSize 16380

"The plain HTTP request was sent to HTTPS port"

nginx returns this 400 when something sends plain HTTP to a port where nginx expects TLS, usually 443; curl http://nginx.org:443/ shows the page. Typical causes are a load balancer or proxy forwarding http:// traffic to port 443, a link with http://example.com:443, or, on nginx older than 1.25.1, an ssl on; line in a server block that also listens on port 80 (1.25.1 removed the directive and newer nginx won't start with it; use listen 443 ssl;).

Make sure each listen line matches what arrives on it: listen 443 ssl; for HTTPS and listen 80; for plain HTTP, with a redirect from 80 to 443. Also make sure the proxy in front talks HTTPS to 443 (or HTTP to 80).

400 Errors From APIs

APIs use 400 for requests that fail validation. If you're calling an API, read the response body, because most APIs explain which field is wrong. Then check that you send valid JSON, the right Content-Type: application/json header, and every required parameter.

If you're building an API, return a body that names the problem (for example, {"error": "email is required"}), and consider 422 Unprocessable Content for requests that are well-formed but semantically invalid, keeping 400 for requests that can't be parsed at all.

400 vs 401, 403, 404, 413, 429 and 431

Our guides to the neighbours: 403 Forbidden, 401 Unauthorized and 429 Too Many Requests. For redirects that loop instead of failing, see ERR_TOO_MANY_REDIRECTS, and the Redirect Checker shows every hop.

If the server accepts the request format but not the HTTP method, you get 405 Method Not Allowed instead.