Free HTTP Status Code Reference
Searchable reference for all HTTP status codes with descriptions, meanings, common causes, and best practices. 100% client-side — your data stays private.
What is an HTTP status code? An HTTP status code is the three-digit number a server returns on the first line of every response, telling the client how the request was handled. The first digit gives the class: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error. Codes and their meanings are defined by RFC 9110 and tracked in the IANA HTTP Status Code Registry.
How to Use the HTTP Status Code Reference
-
Search by number or name — The box matches your text against the code, the official name and the description — so
404,timeoutandredirectall work. Partial numbers work too: typing50narrows the table to the 500-series plus anything else containing those digits. - Narrow to one class — The 1xx to 5xx buttons filter to a single class and combine with whatever is in the search box, which is the quickest way to scan every client error without the successes in between.
- Read the meaning and the likely cause — Each row already shows both: a one-line definition of what the code means, then an italic Cause line naming the situations that typically produce it. Nothing needs expanding — the whole table is the detail view.
- Copy an entry for a ticket or comment — The copy button puts the code, its name, the description and the cause on your clipboard as four plain-text lines, ready to paste into an incident note or a code comment explaining why a particular status was chosen.
- Switch to dark mode while you read — The toggle flips the table to a dark palette for long debugging sessions. The setting applies to the current page view and resets when you reload.
- Keep the link — Your search term is written into the page URL, so a filtered view such as the full 5xx list can be bookmarked or pasted into a runbook.
How HTTP Status Codes Are Organised
Every HTTP response begins with a status line carrying a three-digit integer and a short reason phrase, for
example HTTP/1.1 404 Not Found. Only the number is meaningful to software; the reason phrase is
advisory text that a server may change and HTTP/2 and HTTP/3 drop altogether. The core semantics live in
RFC 9110, the 2022 revision that consolidated the older HTTP specifications, and the complete list of assigned
numbers is maintained by IANA in the HTTP Status Code Registry. This page carries 62 of them — every code in
everyday use, plus the WebDAV and protocol-specific ones you occasionally meet in a log.
The first digit is the part a client must understand. A client that has never heard of 418 is
still required to treat it as a generic 400, which is what makes the scheme extensible: new codes
can be added without breaking older software.
| Class | Meaning | What the client should do | Examples |
|---|---|---|---|
| 1xx | Informational | Keep waiting; the real response is still coming | 100, 101, 103 |
| 2xx | Success | The request worked; use the response | 200, 201, 204, 206 |
| 3xx | Redirection | Further action is needed, usually another request | 301, 302, 304, 307, 308 |
| 4xx | Client error | Fix the request; repeating it unchanged will fail again | 400, 401, 403, 404, 429 |
| 5xx | Server error | The request was valid; retrying later may succeed | 500, 502, 503, 504 |
The 4xx/5xx split is a statement about responsibility, and it is the single most useful thing a status code tells you when something breaks. A 4xx says the server understood you and is rejecting what you sent, so retrying the identical request is pointless. A 5xx says the request looked fine but the server could not complete it, which makes a retry with backoff reasonable. Getting that boundary wrong in your own API — for example returning 500 for a validation failure — sends clients into retry loops over requests that can never succeed.
Choosing the Right Redirect
The 3xx class causes more confusion than the rest of HTTP combined, because the five common codes differ along two independent axes: whether the move is permanent, and whether the original request method survives the redirect.
| Code | Name | Permanent? | Method preserved? | Use it when |
|---|---|---|---|---|
| 301 | Moved Permanently | Yes | No — clients historically switch POST to GET | A URL has changed for good and you want search engines to follow |
| 302 | Found | No | No — same historical rewrite to GET | A temporary detour where the original URL will return |
| 303 | See Other | No | No — GET is explicitly required | After a successful POST, to stop a refresh resubmitting the form |
| 307 | Temporary Redirect | No | Yes | A temporary move where a POST must stay a POST |
| 308 | Permanent Redirect | Yes | Yes | A permanent move on an API where methods and bodies matter |
The method column is the trap. 301 and 302 predate a clear rule, and browsers settled on turning a redirected POST into a GET and dropping the body. 307 and 308 were introduced precisely to remove that ambiguity, so for anything other than plain page navigation they are the safer choice. On the web side, 301 and 308 both pass ranking signals to the new URL while 302 and 307 tell a crawler to keep the old one indexed — which is why a site migration served with 302s often loses traffic that a 301 would have preserved.
304 Not Modified sits in the same class but does something else entirely: it is the answer to
a conditional request carrying If-None-Match or If-Modified-Since, and it means the
cached copy the client already holds is still valid. It carries no body, which is exactly the point — a 304 is
the cheapest successful response there is.
Telling the Common 4xx Errors Apart
400 Bad Request is the generic fallback: the server could not parse or accept the request at all — malformed JSON, a missing required field, a query parameter of the wrong type. Prefer a more specific code when one fits, because 400 tells a client nothing about what to change.
401 Unauthorized is misnamed; it means unauthenticated. The credentials are missing,
malformed or expired, and a correct 401 response includes a WWW-Authenticate header saying how to
authenticate. 403 Forbidden means the opposite: the server knows who you are and is still
refusing. Retrying a 401 with a fresh token can work; retrying a 403 with the same identity never will. Some
APIs deliberately return 404 instead of 403 for resources a user may not even know exist, so
that the response does not leak their existence.
404 Not Found says nothing about whether the resource ever existed. 410 Gone is the stronger statement — it was here, it has been removed deliberately, and it is not coming back — which lets crawlers drop the URL faster than a 404 does. 409 Conflict covers requests that clash with current state, such as two edits racing on the same record, and 422 Unprocessable Content covers syntactically valid requests that fail business rules.
429 Too Many Requests is rate limiting. A well-behaved server sends a Retry-After
header giving either a delay in seconds or an HTTP date; a well-behaved client honours it rather than guessing,
and falls back to exponential backoff with jitter when the header is absent. Hammering an endpoint that is
already returning 429 is the fastest way to earn a longer block.
Returning 200 OK with an error message in the body — a "soft 404" or a soft failure — breaks everything that reads status codes rather than prose: browser caches, monitoring, retry logic, search crawlers and your own dashboards. Whatever the body says, make the status line tell the truth.
Reading 5xx Errors During an Incident
The 500-series codes are worth learning as a set, because in a layered deployment each one points at a different part of the stack. 500 Internal Server Error means your application code threw something it did not handle — the stack trace is in your own logs. 502 Bad Gateway means a proxy or load balancer reached the upstream service and got a reply it could not use, or none at all: the application process is usually crashed, still starting, or listening on the wrong port.
503 Service Unavailable is the deliberate one — the server is up but is refusing work because
it is overloaded, draining connections for a deploy, or in maintenance mode. It is the correct code to serve
during a planned outage, and pairing it with Retry-After keeps crawlers and clients from treating
the outage as permanent. 504 Gateway Timeout means the proxy gave up waiting: the upstream is
alive but slower than the gateway's timeout, which usually points at a slow query or a saturated dependency
rather than a crash.
Because a 5xx describes a server-side failure of an otherwise valid request, retrying is legitimate — but only with backoff, and only for methods that are safe to repeat. A retried GET is harmless; a retried POST can create a second order unless the endpoint accepts an idempotency key.
Frequently Asked Questions
1xx informational, 2xx success, 3xx redirection, 4xx client error and 5xx server error. The first digit is the contract: any client that meets an unfamiliar code must treat it as the generic x00 of its class, so an unknown 4xx is handled like 400 and an unknown 5xx like 500. That rule is what allows new codes to be registered without breaking existing software.
301 Moved Permanently says the resource has a new home and callers should update their links; search engines transfer ranking signals to the target. 302 Found says the detour is temporary and the original URL should stay indexed. Both historically turn a redirected POST into a GET, so when the method must be preserved use 308 for permanent moves and 307 for temporary ones.
401 Unauthorized, despite its name, means unauthenticated — no credentials, or credentials that are invalid or expired — and the response should carry a WWW-Authenticate header. 403 Forbidden means the identity is established and still not permitted. In short: 401 is "I do not know who you are", 403 is "I know who you are and the answer is no".
Stop and wait. Look for a Retry-After header, which gives either a number of seconds or an HTTP date, and honour it exactly. Without that header, back off exponentially with a little random jitter so a fleet of clients does not retry in lockstep. Also check whether the limit is per key, per IP or per endpoint, since the fix differs — caching, batching or requesting a higher quota.
They are always the server's responsibility, which is not quite the same thing. A 5xx says the request was valid but could not be fulfilled, and the trigger may be an unhandled exception, a crashed upstream, an exhausted connection pool or a dependency timing out. A malformed request that produces a 500 rather than a 400 is itself a bug in the server's error handling.
201 Created when the request created a resource, with a Location header pointing at it — that is the whole reason 201 exists. 200 OK when the POST performed an action and the response body carries the result. 202 Accepted when the work was queued and has not happened yet. 204 No Content when it succeeded and there is genuinely nothing to send back, which is also the usual answer to a DELETE.
No. The full code list ships with the page as a JavaScript array and all filtering happens in your browser, so the tool works offline once loaded and no query is transmitted. The search term is copied into the page URL so a filtered view can be bookmarked or shared, and nothing else is stored.
The search matches the number, the official name and the description, but not the italic cause line beneath. Searching "rate limiting" therefore returns nothing even though it describes 429 — search "too many" or "429" instead. Filtering to a class and scanning is often faster than guessing a keyword, since each class holds at most thirty entries.
Use Cases
Decoding an Unfamiliar Code in a Log
Your access log is full of 421s or 431s and neither appears in the framework docs. Search the number here to get the definition and the situations that produce it — HTTP/2 connection reuse and oversized cookie headers respectively.
Choosing Codes While Designing an API
Deciding whether a failed validation is 400 or 422, or whether a queued job returns 200 or 202, is easier with the definitions side by side. Filter to 4xx, scan the list, and pick the code that already means what you are trying to say.
Planning a Site Migration
Before moving a domain or restructuring URLs, confirm which redirect passes ranking signals and which preserves the request method, so the rewrite rules use 301 or 308 deliberately rather than whatever the server template defaulted to.
Triaging an Outage
A dashboard is showing a spike of 502s but no 500s. That split narrows the search immediately: the application process is failing to answer the proxy rather than throwing exceptions, so start with process health and port bindings, not the stack traces.
Writing Integration Tests
Copy the exact code and name into an assertion or a mock so a test asserts expect(res.status).toBe(409) with a comment explaining what a conflict means in that endpoint, rather than a bare magic number nobody can review.
Explaining an Error to a Non-Engineer
Support has escalated "the site says 403". Copy the entry straight into the ticket so the reply distinguishes a permissions problem from a broken link, and nobody spends an afternoon looking for a missing page that was never missing.