What is a 400 Bad Request error?
Every time a browser or an app asks a server for something, the server answers with a three-digit status code. Codes in the 200s mean success, 300s mean a redirect, 500s mean the server failed. The 400s mean the request was the problem, and 400 Bad Request is the most general of them: the server read the request, could not make sense of it and refused to proceed.
The causes are mundane. A URL with characters the server does not accept, or one that is simply too long. A request header or a cookie that has grown past the size limit, which is common on sites that set many cookies. A form or an API call sending data in the wrong format, such as invalid JSON. A corrupted cache or an expired session cookie that no longer parses. A file upload larger than the server allows, which some servers report as 400 rather than the more specific 413.
It is different from its neighbors. A 401 means the request needs authentication, a 403 means the server understood but refuses, a 404 means the page does not exist. A 400 means the request never got far enough to be judged on any of those.
Why it matters
Why a 400 Bad Request matters
For a visitor a 400 is a dead end with no explanation. The page they wanted is replaced by a line of text, and most people leave. For a brand it is a form that silently fails, a checkout that stops, a campaign landing page that returns an error for everyone who arrives with a mistyped tracking link. For a developer it is a signal that something between the browser and the server is broken, and it is often the first visible symptom of a bigger problem.
Search engines notice too. If a crawler receives 400 responses from pages that used to work, those pages drop from the index, and a site that returns errors to a crawler looks neglected. On a campaign, a 400 on the destination page is the fastest way to waste a media budget.
In practice
How a 400 Bad Request works in practice
- 01
Diagnosing a 400 starts with reproducing it. If it happens only in one browser, clearing cookies and cache usually fixes it, because the stored data was the broken part. If the URL is unusual, it is checked for stray characters, bad encoding or excessive length. If it comes from an application or an API call, the request body is compared with what the server expects, and the server logs show exactly what was rejected and why. The browser's developer tools reveal the request and the response side by side.
- 02
Preventing it is the developer's job. Inputs are validated before they are sent, cookies are kept small, URLs are built carefully, and the error page for a 400 is designed like any other page, with the brand on it and a way back. The right code is also chosen honestly: a 400 should mean a bad request, not be the catch-all for every error a server cannot be bothered to name.
Watch out
What people get wrong about 400 Bad Request errors
Blaming the server, when a 400 by definition means the request was at fault, even if the fault was a cookie the server set in the first place. Using 400 as a generic error for everything, which hides the real cause from everyone who has to debug it. Ignoring the errors in the logs because the site looks fine to the people in the office, who have the right cookies. Leaving the default error page, so a visitor sees a line of server text instead of the brand. And forgetting that campaign links, shortened URLs and tracking parameters are a common source, so a launch is the moment to test them.
