How to Fix a 400 Bad Request Error (Browsers, Servers, and APIs)

400 Bad Request is the server telling you it could not make sense of what you sent. Not that it crashed, not that you lack permission, not that the page is missing. The bytes that arrived were malformed, too large, or addressed to a hostname the server does not answer for, so it threw them away before doing any real work.

That makes 400 one of the strangest errors to debug, because it is almost always invisible to the person who owns the site. The most common cause on the visitor side is a single oversized cookie, which means the site works perfectly in your browser and fails in theirs. The most common cause on the server side is a configuration detail that only breaks for one hostname or one kind of request.

This guide covers what a 400 actually means, the visitor fixes that work (and the ones that do not), a one minute diagnosis that identifies which layer rejected the request, the three causes behind nearly every unexpected 400 on a site you run, and how API clients should handle one. If you do not run the site, skip to the visitor section.

What 400 Bad Request Actually Means

HTTP 400 is the generic client error. The specification says the server cannot or will not process the request because of something the client did wrong: malformed syntax, an invalid message framing, or deceptive request routing. Everything in the 4xx range points at the request rather than the server, and 400 is the catch all for requests that fail before any more specific code applies.

In practice, a 400 comes from one of two very different places, and telling them apart is most of the work:

• A transport level 400. Your web server, reverse proxy, or CDN rejected the request while parsing it. The application never ran. Nginx, Apache, IIS, and Cloudflare all do this when headers are too big, the request line is invalid, or the connection is being used in a way they do not allow. The response is a bare, unbranded error page.
• An application level 400. Your code received the request, looked at it, and decided it was invalid. A missing required field, unparseable JSON, a hostname not in the allowed list, or a query parameter that should have been a number. The response usually contains a message written by your framework or your own validation code.

A transport level 400 tends to affect a specific set of visitors, such as everyone with a large cookie, and leaves no trace in your application logs at all. An application level 400 shows up in your logs with a reason attached. The diagnosis section below shows how to tell which one you have in a single command.

400 Compared to the Errors It Gets Confused With

Several errors look like a 400 from the outside, and several servers send a 400 when a more specific code exists. This table is the fastest way to confirm you are debugging the right thing:

If the page you are looking at is actually a 403 or a 429, we have dedicated guides for fixing 403 Forbidden and fixing 429 Too Many Requests.

If You Are a Visitor: How to Fix 400 Bad Request

When one site returns a 400 and every other site works, the problem is almost always something your browser is attaching to the request. Work through these in order, because the first one fixes the large majority of cases.

1. Clear the Cookies for That One Site

This is the fix. Cookies accumulate, and once the total cookie header for a domain grows past the server's limit, every single request you send to that site is rejected before it reaches the application. Clearing your entire browser history is not necessary and logs you out of everything, so target the one domain:

• Chrome and Edge: Click the icon to the left of the address bar, choose Cookies and site data, then Manage on device site data, and delete the entries for that domain. Or open chrome://settings/content/all and search for the domain.
• Firefox: Settings, Privacy and Security, Cookies and Site Data, Manage Data, search for the domain, then Remove Selected.
• Safari: Settings, Privacy, Manage Website Data, search for the domain, then Remove.

Reload the page afterwards. You will be logged out of that one site, which is expected. If the 400 disappears and comes back a few days later, the site has a cookie that grows on every visit, and only the site owner can fix that properly.

2. Look Closely at the URL

A URL containing a raw space, a stray percent sign, or characters pasted from a document with smart quotes will be rejected outright. If you copied the link from an email, a chat message, or a PDF, retype it or copy it again from the source. A URL that ends mid word, or that contains a doubled up %25, has been mangled somewhere in transit.

3. Try an Incognito or Private Window

A private window sends no cookies and loads no extensions. If the page works there, you have confirmed it is something in your profile: either the cookies from step 1, or an extension injecting headers. Disable extensions one at a time, starting with anything that touches privacy, VPNs, or request headers.

4. Check the Size of Your Upload

If the 400 appears only when you submit a form with a file attached, the file is likely over the site's limit. The correct code for this is 413, but plenty of servers and frameworks answer with a 400. Try a smaller file to confirm.

5. Flush Your DNS Cache

Rarely, a stale DNS entry sends you to a server that does not answer for that hostname, and it responds with a 400. Flushing costs nothing:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd)
sudo resolvectl flush-caches

Diagnose It: Find Out Which Layer Rejected the Request

A 400 page in a browser hides the useful part. Run the request from a terminal and read the raw response instead:

curl -v https://example.com/the-failing-path 2>&1 | tail -40

The response body names the culprit far more often than people expect. Match what you see against this table:

Read the Nginx Error Log

Transport level 400s are logged in the error log, not the access log, and the message states the exact reason:

sudo grep -E "too long header line|invalid request|too large|Host header" /var/log/nginx/error.log | tail -20

Typical lines and what each one means:

• client sent too long header line means headers or cookies exceeded the buffer.
• client sent invalid request while reading client request line means the URL or method was malformed.
• client sent invalid Host header means the hostname was junk or missing.

Count the 400s in Your Access Log

To see whether this is one confused visitor or a real pattern, group by URL and then by hour:

# Which paths return 400 most often
awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# When they started
awk '$9 == 400 {print substr($4, 2, 14)}' /var/log/nginx/access.log | uniq -c

# How many distinct visitors are affected
awk '$9 == 400 {print $1}' /var/log/nginx/access.log | sort -u | wc -l

Many distinct IPs hitting 400 on a single path points to a broken link or a bad client side request your own code generates. Many distinct IPs across all paths points to a header or configuration problem. A sharp start time lines up with your last deploy or DNS change.

Cause 1: Request Headers or Cookies Too Large

This is the single most common source of unexplained 400s on a working site, and the reason the error is so hard to reproduce. Every web server allocates a fixed buffer for incoming request headers. Go past it and the request is discarded during parsing, before any routing, logging, or application code runs.

Cookies are usually what fills that buffer, because they are sent with every request and they only ever grow. Analytics libraries, A/B testing tools, consent managers, ad platforms, and single sign on tokens each add their own. A JWT with a few claims in it can be over 1 KB by itself. Store session data in a cookie instead of server side and the total climbs fast.

The Default Limits

Note the stack effect. If you run Nginx behind Cloudflare in front of Tomcat, the smallest limit in the chain wins, and the error page you see tells you which link broke.

Confirm It in Ten Seconds

Send the same request twice, once clean and once with a deliberately oversized cookie:

# Clean request
curl -s -o /dev/null -w "clean: %{http_code}\n" https://example.com/

# Same request with a 12 KB cookie attached
BLOAT=$(head -c 12000 /dev/zero | tr '\0' 'x')
curl -s -o /dev/null -w "bloated: %{http_code}\n" -H "Cookie: junk=$BLOAT" https://example.com/

If the clean request returns 200 and the bloated one returns 400, you have confirmed the cause and found your limit. To see how close real visitors are to it, open your site and run document.cookie.length in the browser console. Anything over about 4000 characters deserves attention, and anything approaching 8000 is already breaking for some people.

Raise the Limit

Raising the buffer is the immediate fix. For Nginx, in the http block of /etc/nginx/nginx.conf:

http {
    client_header_buffer_size   4k;
    large_client_header_buffers 8 32k;
}

sudo nginx -t && sudo systemctl reload nginx

The equivalents elsewhere:

# Apache (httpd.conf)
LimitRequestFieldSize 32768
LimitRequestFields 100

# Tomcat (server.xml connector)
maxHttpHeaderSize="32768"

# HAProxy (global section)
tune.bufsize 32768

Remember to raise the limit on every hop. Raising it on Nginx while the app server behind it still uses an 8 KB buffer just moves the 400 one layer back.

Then Fix the Real Problem

A bigger buffer buys you time, not a solution. Cookies that grow will eventually pass any limit you set, so shrink what you send:

• Move session data server side. Store an identifier in the cookie and keep the data in Redis or your database. A session cookie should be tens of bytes, not kilobytes.
• Scope cookies with Path and Domain. A cookie set on .example.com is sent to every subdomain and every asset request. Set it on the exact host that needs it.
• Serve static assets from a cookieless domain. Every image and script request currently carries the full cookie payload for no reason.
• Set an expiry on everything. Cookies with no Max-Age linger until the browser is closed or forever. Audit what your tag manager is writing.
• Delete the stale ones. If a past version of your app wrote cookies you no longer read, send Set-Cookie headers that expire them so returning visitors are cleaned up automatically.

Cause 2: Malformed URLs and Bad Encoding

The request line is the first thing a server parses, and it is unforgiving. Anything that is not valid HTTP syntax is rejected immediately with a 400 and an invalid request line in the error log.

What Breaks a URL

• Unencoded spaces and special characters. A space must be %20. Curly braces, angle brackets, pipes, and backticks all need encoding too.
• Invalid percent escapes. A percent sign must be followed by two hexadecimal digits. A bare %, or something like %zz, is a syntax error.
• Double encoding. A value encoded twice turns a space into %2520. This usually produces a 404, but strict frameworks reject it with a 400.
• Control characters and smart quotes. Text pasted from a word processor carries curly quotes and non breaking spaces that look identical to the plain versions and are not valid in a URL.
• Absurdly long URLs. Past the buffer you get a 414, but some proxies answer with a 400 instead. Filter and faceted search pages are the usual offenders.

Encode It Properly

If your own code builds URLs, use the language's encoder rather than string concatenation:

# Python
python3 -c "import urllib.parse; print(urllib.parse.quote('report 2026/Q1.pdf'))"
# report%202026/Q1.pdf

# JavaScript
encodeURIComponent('report 2026/Q1.pdf')
// 'report%202026%2FQ1.pdf'

# curl, which encodes the value for you
curl -G --data-urlencode "q=report 2026 Q1" https://example.com/search

Then find where the bad URLs are coming from. If your access log shows many distinct visitors hitting 400 on the same path, something on your site is generating the link: a template that interpolates an unescaped value, a redirect that concatenates a query string twice, or a marketing campaign URL with a broken parameter. A 400 you generated yourself is far more common than a visitor typing something strange.

Cause 3: Host Header and Scheme Mismatches

This category is the one that takes down a whole site at once, usually minutes after a deploy, a DNS change, or adding a new domain. The request is perfectly well formed. The server just does not accept it for that hostname or on that port.

Plain HTTP Sent to an HTTPS Port

If your response body reads The plain HTTP request was sent to HTTPS port, an unencrypted request arrived on a port configured for TLS. It happens when a load balancer terminates TLS and then forwards over plain HTTP to a port that expects encryption, or when a single Nginx server block listens on both 80 and 443 with ssl enabled.

The fix is to give each port its own server block:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Redirect anyone who reaches this port over plain HTTP
    error_page 497 =301 https://$host$request_uri;
}

Nginx uses the internal code 497 for exactly this situation, and mapping it to a redirect turns a confusing 400 into the behaviour visitors expect.

The Hostname Is Not in the Allowed List

Modern frameworks refuse requests whose Host header they do not recognise, as a defence against cache poisoning and password reset link forgery. Django is the most commonly hit, and it answers with a bare Bad Request (400) page that says nothing about why:

# settings.py
ALLOWED_HOSTS = [
    'example.com',
    'www.example.com',
    '.example.com',   # matches every subdomain
]

The giveaway is in your application log: Invalid HTTP_HOST header followed by the hostname it saw. ASP.NET Core's host filtering middleware behaves the same way and also returns 400. Ruby on Rails returns 403 rather than 400 for a blocked host, which is covered in our 403 Forbidden guide.

Three situations trigger this after everything had been working:

• You added a new domain or subdomain and updated DNS but not the application config.
• A load balancer health check connects by IP address, so the Host header is an IP that is not in the list.
• A proxy is rewriting the Host header to its own internal name instead of passing the original through.

The Proxy Is Rewriting the Host

By default, Nginx sets the Host header on proxied requests to the value of proxy_pass, which is often 127.0.0.1. Your application then sees a hostname it has never heard of. Pass the real one through:

location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

This same misconfiguration is behind several other errors, including rate limiters that treat every visitor as one IP address. If you are also seeing 429s, our 429 Too Many Requests guide covers the proxy header side of it in depth. If a 400 is one of several errors that keep appearing, what causes website downtime maps the common failure patterns.

Getting a 400 From an API You Are Calling

When a 400 comes from an API, the response body almost always explains the problem, and almost every developer throws it away. The first rule is to print it:

import requests

resp = requests.post(url, json=payload, headers=headers)
if not resp.ok:
    # The useful part is here, not in the status code
    print(resp.status_code, resp.text)
resp.raise_for_status()

The Usual Suspects

• Invalid JSON. A trailing comma, single quotes instead of double, an unescaped newline inside a string, or a Python dict printed with str() instead of serialised with json.dumps(). Validate the payload first with jq . payload.json.
• Missing or wrong Content-Type. Sending a JSON body without Content-Type: application/json makes most frameworks fail to parse it, then reject the request as having no body at all.
• Wrong types in the payload. Sending "quantity": "5" where an integer is expected, or a date in a format the API does not accept.
• Missing required fields. Especially after an API version bump that made an optional field mandatory.
• An expired or malformed token. A truncated bearer token can produce a 400 rather than a 401, because the header cannot be parsed at all.

Reproduce It With curl

# Save the exact payload your code sends, then replay it
curl -v -X POST https://api.example.com/v1/orders \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $API_TOKEN" \
  --data-binary @payload.json

Using --data-binary rather than -d matters, because -d strips newlines and can make a broken payload look valid.

For monitoring the health of an API rather than debugging one call, our guide to monitoring an API endpoint covers status codes, response body validation, and authenticated checks.

Catching 400 Errors Before Your Visitors Report Them

The 400 is the most under reported error on the web. It produces an unstyled page with no explanation, so visitors assume the site is broken and leave rather than contacting you. And because the request is rejected during parsing, a transport level 400 often never appears in your application logs at all. You can spend a week not knowing.

An external uptime monitor sends a real HTTP request from outside your network on a fixed schedule and treats anything other than a success code as a failed check. The configuration 400s in Cause 3 are exactly the kind that break the site for everyone the moment a deploy lands, and those show up in a monitor within minutes.

Add the URL and every check sends a real request that has to parse cleanly on your server.

Monitor more than the homepage. A cached homepage can be served by your CDN without ever touching the origin that is rejecting requests, while your login page, checkout, or API fails behind it. Add a monitor for every hostname you own too, since a missing entry in an allowed hosts list breaks exactly one subdomain and leaves the rest healthy.

The incident history gives you the exact minute checks began failing, which is the minute of logs to read.

Get the Alert Where You Will See It

Notifier sends email, SMS, phone call, and Slack alerts on every plan, including the free tier, plus a recovery alert when checks pass again. SSL certificate and DNS monitoring are included free on every plan as well, so a certificate quietly expiring on the same site does not become the next outage. If you need a hand interpreting what a check is returning, the support team usually replies within minutes through the chat widget or support@notifier.so.

The alert names the monitor and the time the incident started.

A Note on Search Rankings

Google treats a 400 as a client error and will not retry it patiently the way it does a 503. A URL that keeps returning 400 to Googlebot gets dropped from the index, and unlike a 429 there is no built in assumption that the situation is temporary. If a configuration change starts returning 400 for your canonical hostname, the traffic loss compounds for as long as it goes unnoticed. That is the strongest argument for monitoring every public hostname rather than just the one you happen to have open in a tab.

How the Common Tools Compare

A 400 caused by a bad deploy is fixed in minutes once you know, so check frequency and alert channels are what matter. Here is how the usual options compare on their free plans:

Pricing changes, so verify before committing. Our comparison of free website monitoring tools covers each free tier in detail, and how to set up website monitoring walks through setup in about five minutes. If 400s are one of several errors that keep surfacing, why your website keeps going down covers the patterns behind recurring problems.

Frequently Asked Questions