The Internet Assigned Numbers Authority registers 64 individually named HTTP response status codes in the range from 100 through 511, and a cheat sheet built from that registry is the most reliable way to look up what a three-digit number means. HTTP response status codes are short numeric signals a server returns with a response so the client can tell, at a glance, whether the request was received, processed, redirected, rejected, or failed at the server. The first digit divides every code into one of five response classes: 1xx informational, 2xx successful, 3xx redirection, 4xx client error, and 5xx server error. That class structure is older than most frameworks and survives because it is short, predictable, and standardized in RFC 9110. A cheat sheet that maps every registered code to a class, a phrase, a concise meaning, a registration state, and an RFC reference gives you a single, authoritative place to answer "what does this code mean" without guessing from server logs alone.
What the IANA HTTP Status Code Registry Contains
A cheat sheet is only as useful as the source it leans on. The registry behind this lookup is the IANA HTTP Status Code Registry, which records every named status code together with its reference RFC, description, and registration state. The HTTP Status Codes tool holds a frozen snapshot of that registry containing 64 individually registered entries, captured on 2026-07-17. The snapshot is intentionally registry-based: it includes rows the IANA has explicitly named and excludes unassigned ranges, vendor-specific codes, and framework-internal values that have no IANA row.
That boundary matters in practice. A server can emit a syntactically valid three-digit number that is not in the registry, and a cheat sheet built only on IANA will not show that number. The boundary also prevents a framework-specific code from being presented as an Internet standard, which would be misleading the moment another client, proxy, or browser tried to interpret it.
The Five HTTP Response Classes
Every HTTP status code belongs to a class defined by its first digit. The class is broader than any single code: 404 Not Found and 429 Too Many Requests are both client errors, but they describe different conditions and usually call for different fixes. The table below summarizes the standardized class structure that RFC 9110 defines.
| Class | Range | Purpose | Typical client action |
|---|---|---|---|
| 1xx Informational | 100–199 | Interim progress; the request was received and the client should continue | Keep sending, wait for the final response |
| 2xx Successful | 200–299 | The request was received, understood, and accepted | Process the response body or status |
| 3xx Redirection | 300–399 | Further action is needed, often a location change or conditional cache check | Follow the redirect or revalidate the resource |
| 4xx Client error | 400–499 | The request was malformed, unauthorized, or cannot be fulfilled as sent | Fix the request, reauthenticate, or stop retrying |
| 5xx Server error | 500–599 | The server failed to fulfill a valid request, often through an upstream or gateway | Retry with backoff, surface logs, escalate |
Reading the class first narrows the troubleshooting path. A 4xx says "look at the request"; a 5xx says "look at the server, the proxy, or the upstream". Treating the class as a quick triage step is one of the most reliable habits you can build around a cheat sheet.
How to Use the HTTP Status Codes Cheat Sheet
The HTTP Status Codes tool exposes the 64-entry registry snapshot through a single search box plus a class selector, so lookup stays fast even when you only remember half of what you are looking for. The exact steps to use it as a cheat sheet are below.
- Open the tool and enter an exact three-digit code, a class pattern such as 4xx, a reason phrase such as Not Found, a concept such as gateway, or an RFC reference such as RFC 9110 in the search box.
- Pick Informational, Successful, Redirection, Client error, or Server error in the class selector when you want to restrict the result set to one response class.
- Read the five fields returned for each match: the numeric code, the reason phrase, the concise meaning, the registration-state label, and the RFC reference.
- Click the linked RFC reference for any code whose exact semantics depend on the request method, headers, cache state, or an extension such as WebDAV.
- Adjust the query when the result is empty; an exact code such as 105 inside an unassigned range returns no row and a clear "no registered entry matched" message rather than a guessed entry.
Filtering happens immediately in your browser, so the text you type is never sent to a remote service. That makes the lookup safe on a shared machine or inside an isolated environment, and it also means the same query always returns the same result because the snapshot does not change between page loads.
Reading an Entry: Phrase, Meaning, State, and RFC
Each row in the cheat sheet carries four fields you should learn to read together rather than separately. The phrase is the standardized reason text, the meaning is a practical paraphrase aligned with the registry, the registration-state label tells you whether the code is current, temporary, deprecated, unused, or obsolete, and the RFC reference points to the governing specification. None of those four fields is a complete answer on its own.
The meaning field, for example, is intentionally short. A code's full semantics can depend on the HTTP method, the headers, the cache state, the authentication context, intermediary behavior, or an extension like WebDAV. The real semantics of a 200 response vary with PUT, POST, or GET, and the meaning beside 401 Unauthorized explains that the response concerns missing or invalid authentication credentials despite the historical reason phrase. When a code carries implementation-critical detail, follow the cited RFC before relying on the paraphrase.
Registration States: Current, Temporary, Deprecated, Unused, Obsolete
Not every entry in the registry is a code you should send. The cheat sheet preserves every named IANA row, but it labels each one with its registration state, and that label is part of the answer. Code 104, Upload Resumption Supported, is a temporary registration tied to an active Internet-Draft, so the row is labeled Temporary rather than presented as a permanent standard. Code 305, Use Proxy, is recorded as deprecated through RFC 9110. Codes 306 and 418 sit in the unused state, and 510, Not Extended, is recorded as obsolete.
Some of those labels match popular assumptions and some deliberately contradict them. The familiar phrase associated with 418 is not the current IANA description; the registry and RFC 9110 label 418 as unused, which is what this tool displays. The same snapshot date caveat applies to any temporary registration: the registry can change, so the snapshot date on the page is material when you are evaluating a newly assigned or expired temporary code.
Limits of a Cheat Sheet When Diagnosing Live Incidents
A cheat sheet tells you what a status code means in HTTP, not why a specific server returned it. A 502 Bad Gateway might reflect an upstream crash, a network path problem, a proxy timeout policy, or malformed upstream output. A 429 Too Many Requests signals rate limiting, but the safe retry behavior depends on the service and may use a Retry-After header. A 404 can conceal a forbidden resource, and a 500 is intentionally generic so it does not leak implementation detail.
For a live incident, treat the cheat sheet as the protocol dictionary and the server logs, response headers, request identifiers, and the relevant service documentation as the case file. The lookup on this site does not contact a URL, does not inspect a server, and does not claim to identify an operational fault. It is a registry-based reference, paired with MDN's HTTP response status code reference as an independent implementation-oriented cross-check, designed to answer "what does this code mean" before you start a deeper investigation.
If you're weighing options, JavaScript Playground Cheat Sheet: Limits at a Glance covers this in detail.