Which HTTP response status code indicates a request was incorrectly formed?

400 Bad Request is the correct status for a request that is incorrectly formed. It covers malformed request syntax, invalid message framing, or similar client-side errors that prevent the server from understanding the request.

Authoritative references: see MDN’s definition of 400 and examples of malformed syntax, and the HTTP Status Code Registry listing for 400 and related 4xx codes (MDN 400 Bad Request; IANA HTTP Status Code Registry; MDN HTTP status codes).

How this differs from 409 Conflict and 412 Precondition Failed

Key distinctions

• 400 Bad Request: the server cannot process the request because it is malformed or invalid at the protocol/message level (for example, broken JSON or invalid request framing). This is the canonical answer for “incorrectly formed.” (MDN 400 Bad Request)
• 409 Conflict: the request conflicts with the current state of the target resource (for example, a write collides with an existing resource or state). It is not about syntax; it is about state conflicts. (MDN status list: 409)
• 412 Precondition Failed: a conditional request’s preconditions in headers (such as If-Match or If-Unmodified-Since) are not met. It signals failed conditional logic, not malformed input. (MDN status list: 412)

Worked scenarios

• Broken JSON body on POST /orders: return 400 with a short parse error message. (MDN 400 Bad Request)
• Duplicate unique value (email already exists) on POST /users: return 409 to indicate a state conflict (the resource already exists). (MDN status list: 409)
• PUT /documents/42 with If-Match: "abc" but the current ETag is "def": return 412 because the precondition failed. (MDN status list: 412)

400 vs 422: malformed input vs semantically invalid content

Some APIs distinguish malformed input (400) from semantically invalid but well-formed content (422). Per the registry and modern docs, 422 Unprocessable Content applies when the server successfully parses the request but cannot process it due to semantic errors. Use 400 for malformed syntax; consider 422 for domain validation failures. (IANA registry: 422 Unprocessable Content; MDN status list: 422 Unprocessable Content)

For deeper background on 422 in application design, see our explainer: What does HTTP 422 mean?

Concrete examples

Example 1: Malformed JSON leads to 400

{ "error": { "code": "bad_request", "message": "JSON parse error at line 1 column 42" } }

Example 2: Well-formed but invalid content leads to 422

{ "error": { "code": "validation_failed", "message": "One or more fields failed validation.", "fields": { "quantity": "must be greater than 0" } } }

Example 3: Conditional update fails precondition, return 412

{ "error": { "code": "precondition_failed", "message": "If-Match ETag does not match current resource version." } }

Example 4: State conflict, return 409

{ "error": { "code": "conflict", "message": "A user with this email already exists." } }

For practical handling of state conflicts, see HTTP 409 Conflict: what it means and how to handle it.

Practical response pattern

• Return a precise 4xx code: 400 for malformed, 422 for semantic validation failures, 409 for state conflicts, 412 for failed conditional requests. (MDN status list; IANA registry)
• Include a machine-readable error.code and a concise error.message.
• For validation errors, include field-level details.

{ "error": { "code": "bad_request", "message": "Request body could not be parsed." } }

FAQ