Skip to main content
chain
#
HTTP 400 Bad Request
⌃⏎ run · ⎋ clear · / focus input
Meaning
send output to
no matches
Result appears here as you type
runs in your browser · nothing uploaded
// about this tool

HTTP 400 Bad Request Online

Updated 2026-10-24

HTTP 400 Bad Request means the server couldn't even parse your request properly, due to malformed JSON, a missing required parameter, or syntax that doesn't match what the endpoint expects. It's a structural problem with the request itself, caught before any real processing begins.

Start by checking the exact shape of what's being sent: valid JSON (no trailing commas, properly escaped strings), the right Content-Type header for the body format, and correctly URL-encoded query parameters. If the request parses fine but a specific field fails a business rule, that's 422 Unprocessable Entity instead. For every other status code at once, use the full HTTP Status Codes reference.

// how to use

  1. 1 The code is already looked up below, with 400 pre-filled.
  2. 2 Type any other status code to look that one up instead.
  3. 3 Copy the result, or use the full HTTP Status Codes reference for every code at once.

// examples

The code itself
Input
400
Output
400 Bad Request: Client Error (4xx). The server cannot process the request due to a client error.
A code it's easy to confuse with
Input
422
Output
422 Unprocessable Entity: the request is well-formed, but the data inside it fails validation.

// common uses

Debugging malformed JSON or query parameters in an API request Distinguishing a structurally broken request (400) from a validation failure (422) Explaining a 400 in API integration documentation Checking what a status code in server logs actually means

// faq

Is anything uploaded to a server?
No. The code is matched against a local table in your browser; nothing leaves your machine. 400 is the oldest, most generic 4xx code, which is why it's the default fallback client error in most frameworks.
What actually triggers a 400?
Malformed request syntax, such as invalid JSON in the body, a missing required parameter, a query string the server can't parse, or a request that violates the API's basic structural expectations before any business-logic validation even runs.
How is 400 different from 422 Unprocessable Entity?
400 means the request itself is broken, such as bad JSON, wrong content type, or malformed syntax. 422 means the request is perfectly well-formed but the DATA inside it fails a validation rule (like a required field being empty or an email being invalid).
My request body looks fine. Why is it still 400?
Common culprits are a trailing comma or unescaped quote in JSON, sending form-encoded data with a JSON Content-Type header (or vice versa), or a query parameter that isn't URL-encoded correctly.
Is a 400 the client's fault or the server's?
The client's fault, since 400 is explicitly a 4xx client error, meaning the request as sent doesn't meet the server's basic requirements. Fixing it means fixing what's being sent, not the server.

Use this via API

Get a free API key →
curl -X POST https://thesnaptools.com/api/v1/tools/http-400 \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"400"}'