What Does HTTP Status 400 Mean? (Bad Request)
What HTTP 400 (Bad Request) Means In Plain English
A 400 status (Bad Request) means the server rejected the request as invalid or malformed.
If you want the broader context across all status code families, use the full HTTP Status Codes Guide (2xx, 3xx, 4xx, 5xx).
Quick Navigation
- What HTTP 400 (Bad Request) Means In Plain English
- How to Read HTTP 400 in WebsiteDown Results
- Most Common Root Causes
- What to Do Next
- What to Avoid During Triage
- Real-World Examples
- HTTP 400 FAQ
How to Read HTTP 400 in WebsiteDown Results
For reachability checks, 400 still proves the server answered. It is usually not a full outage but a request-shape problem.
If you see this code only in one region, compare with official provider status and retest from another network. Mixed regional results often indicate routing, policy, or edge differences rather than full global outages.
For deeper triage, compare this with the HTTP 401 guide, HTTP 500 guide, and the API downtime investigation playbook.
Most Common Root Causes
- Invalid URL encoding or malformed query strings.
- Broken client requests after frontend deployment changes.
- Header formatting issues at proxies or API gateways.
- Oversized or unexpected payload structure.
What to Do Next
- Compare failing request format against known-good examples.
- Check recent client-side or API contract changes.
- Validate URL encoding, headers, and content-type.
- Inspect gateway logs for exact validation rejection reason.
What to Avoid During Triage
- Do not classify 400 as server downtime by default.
- Do not retry malformed requests without fixing payload shape.
Real-World Examples
- Example: malformed JSON body triggers immediate 400 from API gateway.
- Example: invalid encoded path segment causes 400 before app logic runs.