400 Bad Request (tested)

400 Bad Request means the server could not parse or accept the request itself. It is the generic "your request is broken" code. We sent broken requests to real servers and wrote down exactly what came back.

1. What a 400 means

The server got your request but refused it because something in it was malformed. It is a client-side error: retrying the same request gives the same 400. The fix is to change the request.

A 400 can come from two layers. The HTTP parser rejects bytes it cannot read, before your code runs. The framework rejects a body it cannot decode, such as broken JSON. Validation errors in your own code often use 422 Unprocessable Entity instead.

2. Parser-level 400s in Node.js 24 (measured)

We sent raw bytes to a plain http.createServer() on Node.js 24.21.0. For every broken request below, Node replied with exactly this and closed the connection. There is no body, and your request handler never runs.

HTTP/1.1 400 Bad Request
Connection: close

So Node.js 24 does reject HTTP/1.1 requests without Host by default. You can turn that off with http.createServer({ requireHostHeader: false }), but real clients always send Host, so a missing one usually means a broken hand-written client.

Headers that are too large get a different code. See 431 Request Header Fields Too Large.

3. Malformed JSON in Express (measured)

With app.use(express.json()) on Express 5.2.1, we posted {"a":1,} (trailing comma) with Content-Type: application/json. The parser raised an error with status 400. Our error handler printed its fields:

HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8

{"type":"entity.parse.failed","message":"Expected double-quoted property name in JSON at position 7 (line 1 column 8)","status":400}

Check err.type === 'entity.parse.failed' in your error handler to return a clean message instead of a stack trace.

4. Malformed JSON in Flask (measured)

On Flask 3.1.3, reading request.json on the same broken body returned:

400 BAD REQUEST
<title>400 Bad Request</title>
<h1>Bad Request</h1>
<p>The browser (or proxy) sent a request that this server could not understand.</p>

The page does not say the JSON was the problem. Two more results from the same run:

• Valid JSON sent as text/plain gave 415 Unsupported Media Type, not 400: "Did not attempt to load JSON data because the request Content-Type was not 'application/json'." See 415 Unsupported Media Type.
• request.get_json(silent=True) on broken JSON returned None and our route answered 200. Use it when you want to send your own error.

5. What clients do before the server sees anything (measured)

So curl and fetch() catch many mistakes on your side. Raw sockets, old libraries and hand-built requests do not, and the server answers 400.

6. 400s you see in the browser (from documentation, not measured)

• nginx "400 Bad Request – Request Header Or Cookie Too Large". The cookies for that site grew past nginx's header buffer. Clear cookies for the site. Full fix: Request Header Or Cookie Too Large.
• Google or YouTube "400. That's an error." Usually a bad or oversized cookie, or a broken URL. Clearing cookies for google.com or youtube.com, or trying a private window, is the usual fix.
• Broken URL encoding. A stray % not followed by two hex digits, or unencoded spaces and quotes, can make a server reject the URL. Encode query values with encodeURIComponent() or your library's equivalent.

7. Quick fix checklist

1. Browser: clear cookies for the site, then reload. Try a private window.
2. Check the URL for spaces, stray % signs or pasted junk.
3. API client: validate your JSON (a trailing comma is enough to fail) and send Content-Type: application/json.
4. Check header names and values for spaces, newlines or non-ASCII characters.
5. Hand-built HTTP/1.1 requests: always send Host and one Content-Length.

Written with AI assistance. Measured on 2026-10-02 with Node.js 24.21.0 (http module), Express 5.2.1, Flask 3.1.3 / Werkzeug 3.1.9 and curl 8.14.1. Raw requests were sent with a Python socket so nothing fixed them on the way. The nginx, Google and cookie notes come from documentation, not our runs. PlainHeaders is our extension; curl, Node.js, Express and Flask are free.