HTTP 400 Bad Request

What It Means

The HTTP 400 Bad Request status code indicates that the server cannot process the request due to something perceived as a client error. The request is malformed, invalid, or deceptive.

Common Causes

Invalid JSON: Malformed JSON in request body
Missing required fields: Required parameters not provided
Invalid data types: String where number expected, etc.
URL too long: Query string exceeds server limits
Invalid characters: Unencoded special characters in URL
Corrupt cookies: Malformed or expired cookies
Invalid headers: Malformed or conflicting headers

Example Responses

Generic 400

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "Bad Request",
  "message": "Invalid JSON in request body"
}

With validation details

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "Validation Error",
  "details": [
    {"field": "email", "message": "Invalid email format"},
    {"field": "age", "message": "Must be a positive number"}
  ]
}

How to Debug

Check the request body: Validate JSON syntax
Verify Content-Type: Ensure header matches body format
Check required fields: Read API documentation
Inspect URL encoding: Encode special characters
Clear cookies: Try in incognito mode
Check server logs: Look for specific validation errors

Quick Fixes

# Validate JSON
echo '{"name": "test"}' | jq .

# Check URL encoding
curl -v "https://api.example.com/search?q=hello%20world"

# Test with minimal request
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"email": "[email protected]"}'

400 vs Other 4xx Errors

Code	When to Use
400	Request is malformed/invalid
401	Authentication required
403	Authenticated but not authorized
404	Resource doesn't exist
422	Valid syntax but semantic errors

Best Practices for APIs

Return specific error messages explaining what's wrong
Include field-level validation errors when applicable
Use consistent error response format across your API
Log details server-side for debugging

Frequently Asked Questions

What does HTTP 400 Bad Request mean?

HTTP 400 Bad Request indicates that the server cannot process the request because it is malformed, contains invalid data, or has incorrect syntax. It is a client-side error meaning the problem is with the request itself, not the server.

What are the most common causes of 400 errors?

The most common causes include invalid JSON in the request body, missing required fields, incorrect Content-Type headers, URL encoding issues, corrupted cookies, data type mismatches (sending a string where a number is expected), and exceeding query string length limits.

How do I fix a 400 Bad Request error?

First, check the response body for specific error details. Validate your JSON with a linter, verify required fields are present, ensure Content-Type matches the body format, URL-encode special characters, and try the request in an incognito window to rule out cookie issues.

What is the difference between 400 and 422?

400 Bad Request means the request has syntactic errors (malformed JSON, invalid encoding). 422 Unprocessable Entity means the syntax is valid but the data has semantic errors (valid JSON but email format is wrong). Some APIs use 400 for both cases.

How do I monitor for 400 errors?

UptimeSignal sends properly formatted requests to your endpoints and alerts you if they return unexpected status codes. A sudden increase in 400 errors from monitoring might indicate a server-side configuration change or deployment issue.