HTTP Status Codes
Everyday status codes with one-line meanings and the typical culprit, filterable.
Status codes are the vitals of HTTP: 2xx good news, 4xx your fault, 5xx mine — the broad strokes everyone knows. What actually matters while debugging is the boundaries: 401 vs 403, 502 vs 504, what 307 does to a POST that 302 does not. This reference lists the common codes with a one-line meaning and a note on who is typically to blame.
Content follows RFC 9110 (and successors), covering 30-plus everyday codes across the informational, success, redirection, client-error and server-error classes. Filter by code or name (404 or redirect both work) or by class.
The confusable pairs
401 vs 403: 401 is unauthenticated (no login or a dead token), 403 is authenticated-but-denied. 502 vs 504: 502 means the proxy got an invalid response from upstream (upstream broke), 504 means the proxy timed out waiting (upstream slow). 301/302 vs 307/308: permanent vs temporary, and 307/308 preserve the request method where 302 routinely degrades POST to GET in practice.
422 vs 400
400 means the request is broken at the syntax level (unparseable JSON, missing parameter); 422 means it parsed but is semantically wrong (bad email format, out-of-range value). Mapping validation failures to 422 and structural errors to 400 lets the frontend tell "fix the request shape" from "fix the field value".
Frequently asked questions
- Who sends the status code — browser or server?
- The server side, including reverse proxies and CDNs. A 502/504 you see in the browser is usually Nginx or the CDN speaking, not your application — separate the speakers before debugging.
- Why are some codes missing?
- This table covers the everyday set; reserved codes (418) and WebDAV extensions (207) are off the common debugging path.
- How do I reproduce these codes?
- Convert an example command with the curl converter and fire a real request; time-related behavior like 408/429 pairs well with the timestamp tools.