400 Bad Request - HTTP Status Code

Meaning & Description

The 400 Bad Request status code indicates that the server could not understand the request due to invalid syntax, a malformed request message framing, or deceptive request routing. It acts as a generic client-side error when no other 4xx error code is appropriate.

Common Causes

Malformed JSON or XML body
Missing required fields in the payload
Invalid characters in the URL or headers
Exceeding maximum request size limits (sometimes 413 is preferred)

How to fix a 400 error

Inspect the request body syntax for trailing commas or missing brackets.
Check the API documentation for required headers and parameters.
Review the URL for unencoded special characters.
Examine the server logs for schema validation errors.

Browser & SEO Behaviour

Browser Behavior

Displays a generic browser error page or renders the custom HTML response sent by the server. Does not retry automatically.

SEO Impact

Search engine crawlers will drop the URL from the index if a 400 is returned consistently, as it indicates a broken link or malformed request.

CDN Behavior

Typically not cached by default. Some CDNs may serve a custom error page if configured.

Code Examples

Node.js (Express)

app.post('/api/users', (req, res) => {
  const { email } = req.body;
  if (!email || !email.includes('@')) {
    return res.status(400).json({ error: 'Invalid or missing email address.' });
  }
  // Proceed with creation
});

Python (FastAPI)

from fastapi import FastAPI, HTTPException

app = FastAPI()

@app.post("/items/")
async def create_item(item_id: int):
    if item_id < 1:
        raise HTTPException(status_code=400, detail="Item ID must be positive.")
    return {"item_id": item_id}

Go (net/http)

func handler(w http.ResponseWriter, r *http.Request) {
    if r.URL.Query().Get("id") == "" {
        http.Error(w, "Missing 'id' parameter", http.StatusBadRequest)
        return
    }
}

C# (ASP.NET Core)

[HttpPost("login")]
public IActionResult Login([FromBody] LoginDto dto)
{
    if (!ModelState.IsValid)
    {
        return BadRequest(ModelState);
    }
    return Ok();
}

curl

curl -X POST http://api.example.com/data \
  -H "Content-Type: application/json" \
  -d '{"name": "test", }' # Note the trailing comma causing a 400

Raw HTTP Response Example

HTTP Response

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

{
  "error": "ValidationFailed",
  "message": "Field 'age' must be a number"
}

Real-world Examples

Stripe API: Returns 400 for missing required parameters or invalid card details.

GitHub API: Returns 400 when submitting a pull request with invalid JSON data.

Twilio API: Returns 400 if the "To" phone number is improperly formatted.

Frequently Asked Questions

What is the difference between 400 and 422?

400 is generally used for syntactically invalid requests (like malformed JSON), while 422 Unprocessable Entity is used when the syntax is correct but the semantic content is invalid (e.g., a missing required field).

Can a 400 Bad Request be cached?

No, by default 400 responses are not cacheable. Clients should fix the request before retrying.

How do I fix a 400 error in my browser?

Clear your cookies and cache, check the URL for typos, and ensure you are not uploading a file that is too large.

Should I return a 400 for missing authentication?

No, use 401 Unauthorized for missing or invalid authentication credentials.

Is it safe to return the error details?

Yes, but be careful not to reflect raw user input to avoid XSS. Return structured, sanitized validation messages.

Did You Know?

The 400 status code is the most generic client error and often serves as a fallback when no other 4xx code fits.

Many modern web frameworks automatically return a 400 Bad Request when JSON body parsing fails before your controller logic even executes.

Developer Tips

Always provide a response body with structured error details (e.g., JSON) explaining exactly which field caused the 400 error.
Use standardized problem details (RFC 7807) to format your 400 error responses consistently across your APIs.
Do not use 400 for business logic errors; it should strictly represent a problem with the request format or parameters.

Interview Questions

These are questions you might face in a backend or API design interview that touch on HTTP 400.

When would you choose to return a 400 instead of a 500?

I would return a 400 when the failure is due to client input—like malformed JSON or missing parameters. A 500 indicates an unexpected failure on the server side, such as a database connection dropping.

How does 400 differ from 404?

400 means the request itself is malformed or invalid, regardless of the endpoint. 404 means the request is perfectly fine, but the requested resource or endpoint does not exist on the server.

Should a REST API return 400 for an invalid email format?

Yes, a 400 (or 422) is appropriate because the client provided syntactically invalid data for a specific field, preventing the server from processing the request.

Common Interview Mistakes

Confusing 400 Bad Request with 401 Unauthorized or 403 Forbidden.
Suggesting that a 400 error means the server crashed or had an exception.
Failing to mention that 400 responses should include a descriptive error payload to help the client debug.