HTTP Status Code Reference
Searchable HTTP status reference with links to the RFC and common causes for each code.
Privacy: The full status code registry ships with the page as static data. Searching and filtering happen in your browser, and your search terms are never uploaded or logged.
The whole registry ships with the page, so filtering is instant and works offline. Nothing you type leaves your browser. Click a code to deep-link it (?code=404) or open its full page.
What it does
Every status code in the IANA registry, in one filterable table, with a link to
the exact section of the exact document that defines it. Type 404, or gateway,
or Retry-After, or RFC 6585 and the list narrows as you type. Filter by class
with the 1xx–5xx buttons. Click a code to pin it as a detail card and deep-link it
as ?code=404, which is the form to paste into a ticket or a runbook.
The point is the citation. Plenty of status code lists exist; most paraphrase a paraphrase, and a few repeat outright errors about which codes preserve the request method. Each row here points at RFC 9110, RFC 4918, RFC 6585, or whichever document actually holds the definition, so you can settle an argument in one click instead of trusting this page.
How it works
The registry ships with the page as a static TypeScript module, so filtering is a
plain array filter over data already in memory. No request fires when you search,
nothing is debounced against an API, and the tool works with the network
disconnected. Search matches the code, the reason phrase, the summary text, and
the spec label, which is why RFC 6585 pulls up the 428/429/431/511 cluster as a
group.
Codes not in the registry are deliberately absent. If you search 599 you get an
empty result and a note explaining why. That is not a gap: RFC 9110 requires a
client to treat any unrecognised code as the generic x00 of its class, so a
599 is handled as a 500 by every conforming client, and a 420 as a 400.
Vendor-invented codes are not a private extension point, they are just a 500 with
extra steps.
The method-preservation trap
The single most expensive misunderstanding in this table is the difference between
the two pairs of redirects. 301 and 302 predate a clear rule about what
happens to the request method, and browsers settled on rewriting a redirected
POST into a GET and dropping the body. That behaviour is now baked into the
web and cannot be changed. So a form that POSTs to a URL which 301s to the
canonical hostname does not fail loudly. It silently arrives as a bodyless GET,
your handler sees no parameters, and you spend an afternoon in the wrong log file.
307 Temporary Redirect and 308 Permanent Redirect exist purely to forbid that
rewrite. Same caching and canonicalisation semantics as 302 and 301
respectively, but the method and body survive. If you want the rewrite, meaning
the POST-redirect-GET pattern that stops a browser refresh from resubmitting an
order, use 303 See Other, which specifies it explicitly rather than relying on a
historical accident.
The other frequent trip-up is 304 Not Modified. Its definition lives in RFC 9110
§15.4.5, but the rules about which headers a 304 must carry and how a cache
updates a stored response belong to
RFC 9111, the caching spec. If
you are debugging a stale asset, the caching document is the one to read.
When to reach for it
Reach for it when a proxy hands you a bare number and you need to know whether the
blame sits with the client, your app, or the hop in between. 502 versus 504
tells you whether the backend died or merely stalled. 401 versus 403 tells you
whether re-authenticating could possibly help. 405 versus 501 tells you
whether the method is unsupported on that route or unsupported by the server
entirely.
It is also useful when designing an API and you want to check that the code you are about to return means what you think it does, and when writing documentation where a deep link to the defining section carries more weight than your assurance. MDN’s HTTP response status codes page is the companion reference for browser-specific behaviour that the RFCs do not describe.
Related tools
- HTTP header inspector to see the status chain and headers a real request produces.
- curl command builder to construct the request that reproduces the code you are chasing.
- TLS certificate inspector when the failure happens before HTTP does.
- DNS lookup when the 502 turns out to be a resolution problem.
- JSON formatter for reading the error body once you have it.
Read the paired guide: Every HTTP status code, and what it actually means.
Frequently asked questions
What is the difference between 401 and 403?+
401 Unauthorized means the request was unauthenticated — no credentials, or credentials that failed — and the response must include a WWW-Authenticate header telling you which scheme to use. 403 Forbidden means the server knows who you are and is refusing anyway; retrying with the same identity will not help. The 401 name is a historical misnomer.When should I use 307 or 308 instead of 302 or 301?+
307/308 whenever the method and body must survive the redirect. Browsers have long converted a redirected POST into a GET on 301 and 302, so a redirected form submission silently loses its body. 307 (temporary) and 308 (permanent) forbid that rewrite. If you actually want POST to become GET, 303 See Other is the code that says so explicitly.Is 422 or 400 the right code for a validation failure?+
400 Bad Request when the request itself is malformed — broken JSON, a bad header, an unparseable query string. Use 422 Unprocessable Content when the syntax parsed fine but the content is semantically wrong, such as a well-formed JSON body that fails your schema or business rules. Both are defensible; be consistent across your API and document the choice.Why do I get a 502 or 504 instead of my application's error?+
502 Bad Gateway means the upstream returned something invalid or closed the connection — usually the process crashed, the container was OOM-killed, or nothing was listening on the port. 504 Gateway Timeout means upstream was reachable but did not answer inside the proxy's timeout. Check the application logs and the proxy's own error log, since the proxy generated the response body you are seeing.Are codes like 599 or 420 real HTTP status codes?+
x00 of its class, so a 599 is handled as a plain 500.Related tools
HTTP Header Inspector
Paste a URL, see the response headers with a plain-English explanation of each.
curl Command Builder
Visual builder for curl commands. Fill in method, headers, and body — copy the exact command.
TLS Certificate Inspector
Fetch a live certificate chain by hostname or paste a PEM. Decodes subject, SANs, validity, key and signature algorithms, fingerprints and embedded SCTs.
→ Read the full guide:How this tool actually works