What Is a 400 Bad Request Error?
A 400 Bad Request error is an HTTP status code that means the server could not understand or process your request because something in it is malformed. The request itself is broken, not the page, so the server rejects it before doing real work. Common causes include a corrupted browser cookie, an invalid or oversized URL, a bad file upload, or a client-side coding error in an API call. Because the fault sits on the sending side, fixes start in the browser or the request, not the website's content.
- Status class
- 4xx client error; the request is faulty, not the server (MDN Web Docs)
- Meaning
- Server cannot process the request due to malformed syntax (RFC 9110)
- Frequent cause
- Corrupted or oversized cookies stored in the browser
- Also triggered by
- Invalid URL characters, oversized headers, or bad API payloads
- First fix to try
- Clear cookies and cache for the affected site (browser-side)
What a 400 Bad Request error means #
A 400 Bad Request error tells you the server received your request but could not make sense of it because the request is malformed in some way. The web page you are trying to reach may be perfectly healthy; the problem is in how the request was constructed and sent. Under the HTTP specification, a 400 signals a client-side syntax or framing problem that the server refuses to process (RFC 9110). For everyday users this usually surfaces after a browser accumulates a corrupted cookie, mistypes a URL, or tries to send something the server considers invalid. For developers, it commonly appears when an API receives JSON it cannot parse or a required field is missing. The key insight is that a 400 points at the sender, so troubleshooting begins with the browser or the request rather than the site's files. If a 400 is blocking part of your live site, our /services/website-rescue team can trace the malformed request to its source.
Why the request, not the page, is at fault #
It helps to picture a request as a package with an address, a label, and contents. A 400 means the package is damaged or wrongly labelled, so the server hands it back without opening it. That is different from a 500 error, where the server itself stumbles, or a 404, where the address points nowhere. Because the fault is on the client side, the same URL can work fine for one visitor and throw a 400 for another whose browser holds a corrupted cookie or is sending an oversized header. This is why clearing browser data resolves so many 400s. When a 400 appears in an application programming interface, the sending code has usually built an invalid payload, wrong syntax, an unexpected character, or a value the endpoint will not accept. Understanding which side owns the error saves hours of looking in the wrong place. Our /services/api-crm-integrations page focuses on building requests that servers accept cleanly the first time.
Common causes you can fix quickly #
Several everyday problems produce a 400, and most are quick to clear. Corrupted cookies are the leading cause; over time a site's stored cookie can become malformed and the server rejects requests carrying it. Clearing cookies and cache for that specific site usually resolves it instantly. A second cause is an invalid URL, often a stray space, an unencoded special character, or an address that is simply too long for the server to accept. A third is an oversized file upload that exceeds the server's limit, which some servers report as a 400 rather than a dedicated size error. Browser extensions that rewrite requests, and outdated cached DNS entries, can also contribute. Because these are client-side, the same page loads fine elsewhere. Start by testing in a private window with extensions off, then clear site data if the error persists. For persistent site-wide 400s, our /services/managed-hosting team can check server-side header and size limits that may be too tight.
Diagnosing a 400 in the browser #
When a visitor hits a 400, a methodical browser check finds the cause fast. First, retry the exact URL in a private or incognito window, which ignores stored cookies and most extensions; if it loads, a cookie or extension is the culprit. Second, clear cookies and cache for that domain specifically rather than everything, so you keep other logins intact. Third, inspect the URL for typos, extra characters, or spaces, and re-type it by hand. Fourth, disable browser extensions one at a time, since ad blockers and privacy tools sometimes mangle requests. Fifth, try a different browser or device to confirm whether the issue follows the user or the site. If the 400 vanishes for everyone after these steps, the fault was local. If it persists across clean browsers and devices, the problem has moved server-side and deserves a closer look. Our /free-website-audit can help confirm whether the error is affecting real visitors and search crawlers.
When the cause is in an API request #
For developers and integrated systems, a 400 most often means the request body or headers are malformed. An API endpoint expecting well-formed JSON will reject a payload with a trailing comma, a missing required field, or a wrong data type. Reading the response body usually reveals the specific complaint.
// Request that triggers a 400 (invalid JSON: trailing comma, missing field)
{
"email": "[email protected]",
"plan": "pro",
}
// Typical 400 response the server sends back:
{
"status": 400,
"error": "Bad Request",
"message": "Malformed JSON: unexpected token near position 48; required field 'name' is missing"
}
// Corrected request body:
{
"email": "[email protected]",
"plan": "pro",
"name": "Acme Plumbing"
}Server-side settings that trigger 400s #
Although a 400 is a client error by definition, server configuration sometimes decides where the line falls. Web servers set limits on how large a request header or cookie can be, and when a request exceeds them, the server may respond with a 400 or the related 431 code. Reverse proxies and content delivery networks add their own thresholds. If many users suddenly see 400s, especially after adding features that store large cookies or long query strings, a header or size limit is a prime suspect. Adjusting these limits, or trimming what your application sends, resolves the issue without weakening security. Overly aggressive request-validation rules in a firewall can also reject legitimate traffic as malformed. Reviewing server and proxy logs shows the exact request that failed and why. Tuning these thresholds sensibly, so genuine requests pass while abusive ones are still blocked, is part of the hosting and security work covered on our /services/managed-hosting page.
How 400 errors affect users and SEO #
A single 400 for one visitor with a bad cookie is harmless and self-correcting. The concern is a pattern: if many visitors or search crawlers receive 400s, real damage follows. Customers who see a Bad Request page instead of your content often leave and do not return, hurting conversions and trust. When Googlebot encounters 400s on pages that should be public, it cannot read the content and may drop those pages from the index over time (Google Search Central). Malformed internal links, broken tracking parameters, or a misbehaving script can generate 400s at scale without anyone noticing until traffic dips. That is why monitoring matters: watch server logs and Search Console for spikes in 4xx responses, and test key user journeys regularly. Catching a systematic 400 early prevents a slow bleed of visitors and rankings. Our /free-website-audit surfaces widespread client errors so you can fix the root cause before it costs you customers.
Tools and headers for debugging a 400 #
When a 400 is not obvious, a few tools quickly reveal the malformed part of the request. Your browser's developer tools show the exact request that failed, including its headers, cookies, and any payload, so you can spot an oversized cookie or a bad character. Command-line tools such as curl let you resend a request in a controlled way and read the full server response, which often contains a message naming the specific problem. For APIs, logging both the request you send and the response you receive is invaluable, because the server's error body usually pinpoints the invalid field or syntax. On the server side, access and error logs record the offending request so you can see whether a header-size or validation rule rejected it. Testing in a private window with extensions disabled isolates browser-side causes fast. Combining these approaches, developer tools for visitors and logs plus curl for developers, turns a vague Bad Request into a specific, fixable fault. Our /services/api-crm-integrations team uses exactly these methods to trace malformed requests to their source.
Preventing and resolving 400 errors #
Most 400s are prevented by clean inputs and sensible limits. On the user side, there is little you can control beyond guiding visitors to clear cookies when they report the error, which resolves the majority of cases. On the site side, validate and encode any URLs, query strings, and form data your application generates so it never sends malformed requests to itself. For integrations, build and test request payloads carefully, handle errors gracefully, and log the server's response message so you can see exactly what it rejected. Keep server and proxy header limits reasonable, and avoid storing bloated cookies. When a 400 does appear, work from the client outward: private window, clear site data, check the URL, then move to logs and server settings only if it persists everywhere. If a 400 is affecting real customers or your API integrations, our /services/api-crm-integrations and /services/website-rescue teams can find and fix the malformed request at its source.
FAQ
What is the simplest explanation of a 400 Bad Request error?
It means the server could not understand your request because something in it is broken or malformed. The web page is usually fine; the request itself is the problem. It is like handing someone a form filled out so badly they cannot read it, so they hand it straight back without processing it.
How do I fix a 400 Bad Request as a visitor?
Start by clearing cookies and cache for the affected website, since a corrupted cookie is the most common cause. Then check the URL for typos or stray characters, try a private browsing window, and disable browser extensions one at a time. Testing on another browser or device confirms whether the problem is local to you.
Why does one website give me a 400 error but others work fine?
Because the problem is usually tied to that specific site's stored data in your browser, most often a corrupted cookie or a cached entry for that domain. Other sites use their own separate cookies, so they are unaffected. Clearing site-specific data for the problem domain typically fixes it without disturbing your other logins.
Can a 400 error be caused by the server?
Technically a 400 is a client-side error, but server settings decide the boundaries. If a request exceeds header or cookie size limits, a firewall's validation rules, or a proxy threshold, the server returns a 400. So while the request is deemed faulty, overly strict server configuration can trigger 400s for otherwise legitimate traffic.
What causes a 400 error in an API call?
Usually a malformed request body or headers: invalid JSON, a missing required field, a wrong data type, or an unexpected character. The endpoint cannot parse or accept the payload, so it rejects it. Reading the error message in the response body normally tells you exactly which part of the request the server refused.
Do 400 errors affect SEO?
A one-off 400 for a single user does not. But if search crawlers repeatedly receive 400s on pages that should be public, Google cannot read that content and may remove those pages from its index. Systematic 400s from broken links or scripts can quietly erode traffic, so monitor server logs and Search Console for spikes.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?