Blog
3 min read

400 Bad Request: What It Means and How to Fix It

A 400 Bad Request means the server couldn't or wouldn't process your request because something about the request itself is wrong — invalid JSON, a missing field, the wrong Content-Type, an oversized cookie or a malformed URL. How to find the cause in DevTools and fix it, whether you're a visitor or the developer.

400 Bad Request means the server looked at your request and decided the request itself is wrong. It's the server saying, "I can't work with what you sent me."

Unlike a 500 error, which is the server's fault, a 400 points at the client — the browser, app or script that made the request.

If you're just visiting a website

Most 400s in a browser come from bad cookies or a broken link:

  1. Clear cookies for that site. Oversized or corrupted cookies are the most common cause — you'll sometimes see "Request Header Or Cookie Too Large". (Cookies Explained)
  2. Check the URL for stray characters, spaces or a half-copied link.
  3. Hard refresh or try a private window. (Hard Refresh and Clear Cache)
  4. Try a smaller file if you were uploading.

If you're the developer

Find the exact request in your browser's DevTools → Network tab and read the response body. Good APIs explain what's wrong:

{ "error": "email is required" }

Then check these, roughly in order of likelihood.

Invalid JSON

A trailing comma, single quotes, or sending a JavaScript object without JSON.stringify:

// Wrong: sends "[object Object]"
fetch('/api/users', { method: 'POST', body: { name: 'Ana' } })

// Right
fetch('/api/users', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'Ana' }),
})

(What Is JSON?)

Missing or wrong Content-Type

If the server expects JSON and you don't send Content-Type: application/json, many frameworks won't parse the body at all, so every field looks missing.

Validation failures

A required field is missing, a value is the wrong type ("5" instead of 5), or a date is in the wrong format. Many APIs return 400 for these (some use 422). Log the exact payload you sent and compare it with what the API expects. (Validate Input With Zod)

Bad query parameters or URL encoding

Spaces, &, # and non-English characters need encoding in URLs. Use encodeURIComponent() or URLSearchParams rather than gluing strings together. (Query Parameters Explained)

Headers too large

Big cookies or a huge Authorization header can exceed the server's header size limit. Nginx returns 400 Request Header Or Cookie Too Large. Shrink what you store in cookies.

Plain HTTP sent to an HTTPS port

Nginx returns 400 The plain HTTP request was sent to HTTPS port when something sends http:// traffic to port 443 — often a misconfigured proxy or health check.

400 vs other 4xx errors

Code Meaning
400 The request is malformed or invalid
401 You need to authenticate (401 vs 403)
403 You're not allowed (403 Forbidden)
404 Nothing exists here
405 Wrong HTTP method (405 Method Not Allowed)
413 Body too large (413 Request Entity Too Large)
429 Too many requests (429 Too Many Requests)

The summary

  • 400 means the request itself is wrong.
  • Visitors: clear cookies, check the URL.
  • Developers: read the response body, then check JSON, Content-Type, validation, encoding and header size.

EasySpawn gives Claude Code access to your app's logs on the same server, so it can match a 400 to the exact request and validation rule that rejected it. See how it works or join the waitlist.

Related: HTTP Status Codes Explained · How to Test an API · Failed to Fetch · Unexpected Token < in JSON

Keep reading