The 400 Bad Request error is one of the most common client-side HTTP errors on the web. Unlike a 404 (which means a page does not exist) or a 500 (which points to a server problem), a 400 means the server received your request but could not understand it because something in the request itself was malformed. In this guide we will explain what causes it, how to fix it as a user, and how developers should handle it on the server side.
What is the 400 Bad Request error?
When your browser or an application sends a request to a web server, that request has to follow a specific structure defined by the HTTP protocol. If any part of it is broken — a corrupted cookie, an oversized header, invalid characters in the URL, or malformed JSON in the body — the server rejects the request before processing it and returns a 400 status code.
It belongs to the 4xx family of HTTP status codes, which are reserved for client errors. This is the same family as the 401 and 403 errors and the well-known 404 Not Found error. The key distinction is that a 400 is a generic “the request is broken” signal, while the others point to more specific situations. You can see the full list on the official MDN HTTP status reference.
How the 400 error fits among other HTTP status codes
The table below shows how the 400 compares to its closest relatives in the 4xx and 5xx ranges. Seeing them side by side makes it clear when each one applies.
| Code | Meaning | Typical cause | Side at fault |
|---|---|---|---|
| 400 | Bad Request | Malformed syntax, bad cookie, invalid header | Client |
| 401 | Unauthorized | Authentication missing or invalid | Client |
| 403 | Forbidden | Authenticated but lacks permission | Client |
| 404 | Not Found | Resource does not exist on the server | Client |
| 500 | Internal Server Error | Server-side fault or misconfiguration | Server |
Most common causes of the 400 error
A 400 Bad Request can be triggered by several different problems. The chart below shows roughly how often each cause appears in practice, based on typical support-ticket patterns — useful for knowing where to look first.
As the chart shows, corrupted cookies are by far the most frequent culprit. Cookies are small files your browser stores to keep you logged in and remember preferences; when one becomes corrupted or expired, the server may reject the entire request. You can read more about how they work on the MDN cookies guide.
How to fix the 400 Bad Request error (for users)
If you are seeing this error while browsing, try these steps in order: clear the cookies and cache for the specific site, double-check the URL for typos or invalid characters, disable browser extensions that may alter requests, and try the page in a private window. If you reached the page through a link, make sure the URL was not truncated or corrupted along the way. If the problem only appears when uploading a file, the file may exceed the server’s size limit.
How to handle the 400 error (for developers)
If you run the server or API, a 400 should be returned only when the client genuinely sent something the server cannot parse — invalid JSON, a missing required field, or a malformed query string. Crucially, a 400 means “do not retry this request unchanged.” This is different from authentication problems, where the correct response would be a 401 or 403, and from a server fault, which should return a 500 error. Always return a clear error body explaining what was wrong so the client can correct it. The full semantics are defined in the IETF specification, RFC 9110.
Frequently asked questions about the 400 Bad Request error
What does the 400 Bad Request error mean?
How do I fix a 400 error in my browser?
Is a 400 error caused by the website or by me?
What is the difference between a 400 and a 404 error?
When should an API return a 400 status code?
Conclusion
The 400 Bad Request error always points back to something wrong in the request itself, not the destination. For users, the fix is usually as simple as clearing site cookies or correcting the URL. For developers, the key is precision: reserve the 400 for genuinely malformed requests and use the right code for everything else. Getting this right keeps your site predictable for both visitors and the automated clients that talk to it.
