400 Bad Request 4xx

What does 400 mean?

A 400 Bad Request response means the server can't process the request because something about the request itself is malformed, invalid, or doesn't make sense — before the server even gets to the point of checking permissions (401/403) or looking for a resource (404). It's the most generic of all the 4xx codes, serving as a catch-all for "I literally cannot understand or parse what you sent me."

This is distinct from validation errors on otherwise well-formed data (commonly 422) — a 400 typically means the request couldn't even be properly parsed or is missing something fundamentally required, like malformed JSON syntax or a required header.

How a 400 behaves

• It can carry a body — most APIs include a message explaining what was wrong with the request, which is genuinely useful here (unlike 500, where details should be hidden)
• It's not cacheable — a bad request is specific to that particular request's content
• Fixing it requires changing the request — unlike 429 or 503, waiting and retrying the identical request will never help; the request itself must change
• It's evaluated early — a 400 generally means the server stopped processing before authentication, authorization, or resource lookup even happened, because the request couldn't be understood well enough to get that far

Common causes

If you're building the API or website:

• Your input validation is correctly rejecting malformed requests — 400 here is often the system working as intended
• Your API documentation doesn't clearly specify required fields, formats, or content types, leading clients to send requests you have to reject
• Inconsistent error messages make it hard for API consumers to understand which part of their request was bad

If you're calling an API:

• Malformed JSON — a trailing comma, missing quote, or unescaped character that breaks parsing entirely
• Missing required fields in the request body or query string
• Wrong Content-Type header — sending form-encoded data while claiming application/json, or vice versa
• Sending a value of the wrong fundamental type — a string where the API expects a number, or an object where it expects an array
• An oversized request — some servers return 400 (others use 413) when a request body exceeds size limits

If you're a website visitor:

• A form on the site has a bug that's sending malformed data
• A browser extension is interfering with form submissions
• An unusually long input (pasting a huge block of text into a small field) triggers a server-side limit

How to fix it

As an API/website builder:

• Return specific, actionable error messages — "400: missing required field 'email'" is far more useful than just "400: Bad Request"
• Validate Content-Type headers explicitly and return a clear error if the wrong type is sent
• Document expected request formats thoroughly, including examples of valid request bodies
• Consider using 422 instead of 400 for requests that are well-formed but fail business-logic validation (the request parses fine, but a field value doesn't meet requirements) — this distinction helps API consumers debug faster

As an API consumer:

• Validate your JSON syntax before sending — a linter or JSON.stringify/json.dumps round-trip catches most syntax issues
• Double-check the Content-Type header matches the actual body format
• Read the response body carefully — most APIs explain exactly what was wrong with a 400
• Compare your request against the API's documented examples field-by-field, especially for nested objects and arrays

As a website visitor:

• Try reducing the amount of text/data you're submitting, especially in file uploads or large text fields
• Clear the form and re-enter the information — sometimes browser autofill or extensions corrupt form data
• Try a different browser or disable extensions if the problem persists across multiple attempts

400 vs related codes

Real-world examples

Most REST APIs return 400 for malformed JSON, missing required parameters, or invalid query string formats — Stripe's API, for instance, returns 400 for requests with invalid parameters before it even attempts to process a payment, distinguishing this from 402 (payment-specific failures) and 422 (validation failures on otherwise well-formed data). This layered approach — 400 for "I can't read this," 422 for "I read this, but it's not valid," — is a common pattern across well-designed APIs.

SEO implications

400 errors are rare on normal page navigation (they're far more common on API endpoints and form submissions than on regular page loads), so they don't typically have direct SEO implications for content pages. However, if a site's server misconfiguration causes legitimate crawler requests to be flagged as malformed (unusual but possible with overly strict header validation or WAF rules), pages could fail to be crawled — worth checking server logs if pages aren't being indexed despite working fine in a browser.

FAQ

What's the difference between 400 and 422?

400 generally means the request itself is malformed — broken syntax, missing required structure, wrong content type. 422 means the request is syntactically fine and was successfully parsed, but the data within it fails validation rules (e.g., an email field that doesn't contain a valid email address).

Will retrying a 400 request ever work without changes?

No. A 400 means there's something wrong with the request itself — retrying the exact same request will produce the exact same 400. The request needs to be modified before it will succeed.

Why does my JSON request return a 400 when it looks correct?

Common culprits include trailing commas, single quotes instead of double quotes, unescaped special characters within strings, or a mismatched Content-Type header. Running your JSON through a validator is the fastest way to catch syntax issues.

Is 400 used for security reasons like 403/404 sometimes are?

Less commonly. 400 is primarily a parsing/format signal rather than a security one, though some servers do use 400 generically to avoid revealing more specific information about why a request failed.

Can a 400 happen even with a correct API key and permissions?

Yes — 400 is evaluated based on the structure and format of the request, often before authentication is even checked. You can have perfectly valid credentials and still get a 400 if the request body itself is malformed.

Fun fact

400 is the lowest-numbered status code in the 4xx "client error" range, making it the conceptual starting point of an entire category — every other 4xx code (401, 403, 404, and beyond) is essentially a more specific variant of "something about your request is the problem," with 400 serving as the catch-all when nothing more specific applies.