HTTP 400 Bad Request

HTTP 400 Bad Request — The server can't process the request because it's malformed or invalid.

Class

4xx Client Error

Defined in

RFC 9110 §15.5.1

Official

Yes (IANA registry)

Cacheable by default

No (unless Cache-Control/Expires say so)

Safe to retry

Not without changing the request

What does HTTP 400 mean?

400 Bad Request means the server won't process the request because of something it considers a client error — malformed syntax, an invalid request message, or deceptive routing. It's the generic "your request is wrong" status, used when no more specific 4xx fits.

Because it's generic, the response body is what matters: good APIs explain exactly which field or header was invalid.

When is 400 used?

• The JSON body can't be parsed (trailing comma, single quotes, truncated payload).
• Required query parameters are missing or have the wrong type.
• Headers or cookies are malformed or too large (nginx shows "400 Request Header Or Cookie Too Large").
• An HTTPS port receives plain HTTP (nginx: "The plain HTTP request was sent to HTTPS port").

Common causes of a 400

• Corrupted or oversized cookies for the site.
• A mistyped URL containing invalid characters or bad percent-encoding (e.g. a lone %).
• Client code sending JSON without Content-Type: application/json, or sending a body the server can't parse.
• A stale cached page submitting an outdated form.

How to fix 400 Bad Request

If you're visiting the site

1. Check the URL for typos or stray characters.
2. Clear cookies and cached data for that site — the most common fix for browser 400 errors.
3. Try a private window or another browser, and disable extensions that modify requests.
4. If uploading a file, make sure it's not too large or corrupted.

If you run the site or API (developers)

1. Return a body explaining the problem, e.g. {"error": "invalid_json", "message": "Unexpected token } at position 41"}.
2. Use 422 for well-formed input that fails validation, 415 for the wrong content type, 413/431 for size problems — reserve 400 for malformed requests.
3. Log the raw request (minus secrets) when 400s spike; they often reveal a client bug after a deploy.
4. Check reverse-proxy limits (nginx large_client_header_buffers) if 400s mention headers or cookies.

Returning or handling 400: server examples

# Raise header/cookie limits that trigger "400 Request Header Or Cookie Too Large"
http {
    large_client_header_buffers 4 32k;
}

app.use(express.json());
// express.json() rejects bad JSON with a 400 SyntaxError — format it:
app.use((err, req, res, next) => {
  if (err.type === "entity.parse.failed")
    return res.status(400).json({ error: "invalid_json", message: err.message });
  next(err);
});

// app/api/example/route.ts (Next.js App Router)
export async function POST(req: Request) {
  const body = await req.json().catch(() => null);
  if (!body) return Response.json({ error: "invalid_json" }, { status: 400 });
  // ...
}

Example 400 response

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

{"error":"invalid_json","message":"Expected ',' or '}' after property value at line 3 column 5"}

Related status codes

• 422 Unprocessable ContentThe request is well-formed, but its contents fail validation.
• 415 Unsupported Media TypeThe server refuses the request because the body's format (Content-Type) isn't supported.
• 431 Request Header Fields Too LargeThe server refuses the request because a header — or all headers together — is too large.

Related tools

• HTTP status codes — full list
• HTTP headers reference
• cURL converter
• Mock API — fake REST endpoints with custom status codes
• Webhook tester — inspect incoming requests