400

HTTP 400 Bad Request

4xx Client Error

4xx Client Error RFC 7231, Section 6.5.1

What is HTTP 400 Bad Request?

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something perceived as a client error — malformed request syntax, invalid request message framing, or deceptive request routing. This is a generic client error response that should be accompanied by an error message explaining the specific problem.

Common Use Cases

  • Malformed JSON or XML in API requests
  • Invalid query parameters
  • Missing required headers
  • Request body parsing errors

Usage Example

When your API receives a POST request with invalid JSON, catch the parse error and return 400 Bad Request with a message explaining the syntax issue. Include details about what field or structure is malformed, and provide examples of the correct format when possible.

// Laravel - returning 400 for malformed JSON
try {
    $data = json_decode($request->getContent(), true, 512, JSON_THROW_ON_ERROR);
} catch (\JsonException $e) {
    return response()->json([
        'error' => 'Invalid JSON',
        'message' => $e->getMessage(),
    ], 400);
}

Common Mistakes

⚠️

Mistake: Returning 400 for validation errors instead of 422

Fix: Use 422 Unprocessable Content for semantic validation errors (e.g., missing fields, invalid email format). Reserve 400 for syntactical errors like malformed JSON, invalid headers, or bad request structure.

⚠️

Mistake: Returning a generic "Bad Request" without details

Fix: Always include a descriptive error message explaining exactly what is wrong with the request. A generic 400 with no explanation forces developers to guess what caused the error.

Last updated: 21 Jun 2026