HTTP 400 Bad Request means the server refused to process your request because it arrived in a malformed form: the server sees a syntax error and cannot understand what you are asking for. The most common cause is corrupted or oversized cookies in the browser, but broken JSON, an overly long URL, or a wrong header can trigger it too.
This article explains what the HTTP standard says about status 400, lists client-side and server-side causes in a clear table, shows how to fix the error as an everyday user and as a developer, and how to quickly diagnose the source.
What HTTP 400 Bad Request means
Status 400 Bad Request belongs to the 4xx class of client errors. Per RFC 9110, §15.5.1, the server returns 400 when it "cannot or will not process the request due to something that is perceived to be a client error" — for example, malformed request syntax, invalid request message framing, or deceptive request routing.
The key word is "client". Unlike 5xx errors, where the server is at fault, a 400 tells you: "I am working fine, but your request is assembled incorrectly." So the first diagnostic step is to figure out what exactly is wrong in the request.
What a 400 response looks like
HTTP/1.1 400 Bad RequestContent-Type: text/html; charset=utf-8Connection: close<html> <head><title>400 Bad Request</title></head> <body><h1>Bad Request</h1></body></html>Causes of a 400 error: client and server
Although a 400 is formally the client's "fault", server configuration can provoke it too (for example, overly strict header-size limits). Here is a summary table of typical causes.
| Cause | Side | What happens | How to fix |
|---|---|---|---|
| Corrupted or oversized cookies | Client | Browser sends stale/broken cookies, header exceeds the limit | Clear the site's cookies |
| Malformed request syntax | Client | Bad request line, stray characters, broken framing | Check how the request is built in code |
| URL or headers too long | Client + Server | URL/header length exceeds the server limit | Shorten the URL, raise nginx buffers |
| Wrong Content-Type / broken JSON | Client | Body does not match the declared type, JSON error | Validate JSON, set the correct header |
| Stale browser cache | Client | Cache holds incompatible request data | Clear cache, reload the page |
| Strict header limits | Server | large_client_header_buffers is too small | Raise the limits in the config |
Corrupted cookies — cause number one
The most common cause of a 400 for ordinary users is "bloated" or corrupted cookies. When the total cookie size exceeds the server's buffer limit (usually 4-8 KB), the server aborts the request with a 400. Symptom: the error appears on only one site, while the same site opens fine in incognito mode.
Broken JSON and wrong Content-Type
When working with an API документацию, a 400 is often caused by an invalid request body. If you declared Content-Type: application/json but sent invalid JSON, the server responds with 400.
POST /api/v1/orders HTTP/1.1Host: example.comContent-Type: application/json{ "name": "John", "amount": } <-- trailing comma, missing valueHow to fix a 400 error as a user
If you hit a 400 as a site visitor, try these in order:
- Clear this site's cookies — in browser settings, delete data for the specific domain.
- Clear the cache and reload the page (Ctrl+F5 / Cmd+Shift+R).
- Check the URL — remove stray characters, trim an overly long link.
- Open the site in incognito mode — if it works, the problem is cookies/cache in your main profile.
- Disable extensions that may interfere with requests.
How to fix a 400 error as a developer
If your own server returns the 400, check request construction and limits. When sending JSON, always validate the body and set the correct header:
curl -v -X POST https://example.com/api/v1/orders -H "Content-Type: application/json" -d '{"name":"John","amount":100}'If the error is caused by large headers (for example, a long JWT in a cookie or the Authorization header), raise the buffers in nginx:
http { large_client_header_buffers 4 16k; client_header_buffer_size 16k;}The -v flag in curl shows both the request headers you sent and the response you received — it is the best way to see what actually reached the server.
How to diagnose the source of a 400
To find where the request breaks, work from simple to complex:
- Reproduce the error in incognito — rule out cookies/cache.
- Replay the request with
curl -v— see the exact headers and body. - Compare a working request against the failing one, header by header.
- Check server logs — nginx writes the reason (e.g. "client sent too long header").
400 versus other 4xx codes: don't mix them up
A 400 is the "generic" answer to a malformed request. But it has more specific neighbors, and a well-designed server returns those instead. Knowing the difference speeds up diagnosis.
- 400 Bad Request — the request syntax is broken and the server cannot parse it at all.
- 401 Unauthorized — the syntax is fine, but authentication credentials are missing.
- 403 Forbidden — you are authenticated, but lack rights to the resource.
- 422 Unprocessable Content — the syntax is fine, but the data fails business validation (e.g. a badly formatted email).
An important nuance: some frameworks return 400 where 422 would be more accurate. If you build an API, try to separate "couldn't parse the request" (400) from "parsed it, but the data is logically invalid" (422) — it makes debugging much easier for your API's clients.
Why the same request fails in one browser but not another
If a 400 reproduces in Chrome but not in Firefox or incognito, the culprit is almost always profile-bound state: accumulated cookies, extensions that rewrite headers, or a stale cached request. Browsers store cookies independently, so a "bloated" set in one profile easily exceeds the server buffer while a clean profile stays under the limit. That is also why clearing a specific site's data is the fastest cure.
How to check the server response
The fastest way to see the status code and the full set of headers is a free HTTP header and response code checker on enterno.io. Enter an address and instantly see the status, request and response headers, redirects, and security hints. This helps you tell a client-side 400 from a server-side 5xx. When diagnosing an API, compare the headers of a working request against the failing one — the difference is usually obvious at a glance: an extra header, a wrong Content-Type, or a missing required parameter.
Related reading
To understand response codes more deeply, read the complete HTTP status code reference, plus breakdowns of neighboring errors: 403 Forbidden and 404 Not Found. If your 400 is cookie-related, see our guide to cookie security flags.
Frequently Asked Questions
Is 400 Bad Request an error on my side or the site's side?
Formally, status 400 belongs to the 4xx class of client errors: the server reports that the request is malformed. But server settings can provoke it too — for example, overly strict header-size limits. Start diagnosis by clearing cookies and cache, then check how the request is built.
Why does a 400 appear on only one site?
Almost certainly corrupted or bloated cookies for that specific domain are to blame. Each site stores its cookies separately, so the problem is isolated. Clear that site's data in browser settings or open it in incognito mode — if everything works there, cookies or cache are the cause.
How do I fix a 400 when posting JSON to an API?
Make sure the request body is valid JSON with no trailing commas or missing values, and that the Content-Type: application/json header matches the actual format. Run the request through curl -v to see what actually leaves for the server, and validate the JSON with any linter before sending.
Why does a long URL cause a 400?
Servers limit the length of the request line and the size of headers (usually a few kilobytes). If the URL or headers exceed it, nginx or Apache aborts the request with a 400. The user fix is to shorten the link; the developer fix is to raise large_client_header_buffers or move data into the POST body.
Does reloading the page help with a 400 error?
A plain refresh rarely helps because the cause is usually stored data. A hard reload with a cache purge (Ctrl+F5) plus deleting the site's cookies is far more effective. If the error disappears afterward, client data was to blame; if not, the problem is in the request itself or the server configuration.