HTTP status code reference
Search every HTTP status code in the IANA registry by number, class or words: meaning, cacheability, retry advice, key headers and the RFC section.
A clear answer. Here’s how.
Each row is an entry of the IANA HTTP Status Code Registry (last updated 2025-09-15), with its registered name and reference. The meaning, sender, retry guidance, key headers and common mistake are written for this page from RFC 9110 section 15 and from the RFCs that the registry names for the other codes (RFC 2295, 2518, 2774, 3229, 4918, 5842, 6585, 7725, 8297 and 8470). A search needs every word to appear in the code, name, class, meaning or key headers; a three-digit number finds that code, 4xx finds a class and 400-410 finds the codes in a span. Cacheable by default lists the codes that RFC 9110 section 15.1 calls heuristically cacheable (200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 and 501), plus 451, which RFC 7725 makes cacheable by default; RFC 6585 says 428, 429, 431 and 511 must not be stored. Any response can be cached when it carries explicit freshness information, so this is only the default. The retry column is general guidance, not a rule of the protocol. 306 and 418 are reserved (Unused) rows, 104 is a temporary registration for an Internet-Draft that IANA expires on 2026-11-13 unless it is extended, and 510 is obsolete. The unassigned ranges are listed as IANA lists them. The vendor codes (nginx 444, 495 to 497 and 499; Cloudflare 520 to 526) are not in the registry; each cites the vendor’s own documentation, and other products may use the same numbers differently. Nothing is sent anywhere: the page does not test any URL or server.
How this is checked
5 reference checks passed These 5 cases were run when this page was built, on 20 October 2026, and all reproduce within the stated tolerance. The same cases are part of the automated tests that run on every change to Toolmoz. Engine version 1.
See the checks and where each expected answer comes from
Case 1
- Inputs
- Search 404
- Expected, and what Toolmoz gave
- Matching rows expected 1, Toolmoz 1Code expected 404, Toolmoz 404Name expected Not Found, Toolmoz Not FoundDefined in expected RFC 9110, Section 15.5.5, Toolmoz RFC 9110, Section 15.5.5Cacheable by default expected Yes, Toolmoz Yes
- Where the expected answer comes from
- IANA HTTP Status Code Registry (updated 2025-09-15): 404 Not Found, reference RFC 9110 Section 15.5.5. RFC 9110 section 15.1 lists 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 and 501 as heuristically cacheable, and section 15.5.5 says so again for 404
- Allowed difference
- exact
Case 2
- Inputs
- Search 4xx
- Expected, and what Toolmoz gave
- Matching rows expected 29, Toolmoz 29First match expected 400 Bad Request, Toolmoz 400 Bad RequestLast match expected 451 Unavailable For Legal Reasons, Toolmoz 451 Unavailable For Legal Reasons
- Where the expected answer comes from
- IANA registry rows for 4xx: 400 to 418 is 19 rows (418 is listed as Unused), 421 to 426 is 6 rows, and 428, 429, 431 and 451 are 4 more, so 19 + 6 + 4 = 29; 419-420, 427 and 430 are listed as Unassigned and are not counted
- Allowed difference
- exact
Case 3
- Inputs
- Search Class 5xx
- Expected, and what Toolmoz gave
- Matching rows expected 11, Toolmoz 11
- Where the expected answer comes from
- IANA registry rows for 5xx: 500 to 508 is 9 rows, 510 (obsoleted) and 511 make 11; 509 and 512-599 are Unassigned
- Allowed difference
- exact
Case 4
- Inputs
- Search 429
- Expected, and what Toolmoz gave
- Name expected Too Many Requests, Toolmoz Too Many RequestsCacheable by default expected No (RFC 6585: must not be stored), Toolmoz No (RFC 6585: must not be stored)Key headers expected Retry-After, Toolmoz Retry-AfterDefined in expected RFC 6585, Section 4, Toolmoz RFC 6585, Section 4
- Where the expected answer comes from
- RFC 6585 section 4: a 429 response may include a Retry-After header, and a cache must not store a 429 response; IANA registers 429 with reference RFC 6585
- Allowed difference
- exact
Case 5
- Inputs
- Search 301
- Expected, and what Toolmoz gave
- Name expected Moved Permanently, Toolmoz Moved PermanentlyCacheable by default expected Yes, Toolmoz YesDefined in expected RFC 9110, Section 15.4.2, Toolmoz RFC 9110, Section 15.4.2
- Where the expected answer comes from
- IANA registry: 301 Moved Permanently, RFC 9110 Section 15.4.2; section 15.4.2 says a 301 response is heuristically cacheable
- Allowed difference
- exact
What this shows: the engine reproduces independently worked values for these cases. It does not prove every possible input is right. To test an answer you were given, see how to check a number; to see what is and is not checked across Toolmoz, see the accuracy ledger.
See a worked example
Worked example
A fixed demonstration, separate from the values you enter above.
- Search
- redirect
- Class
- All classes
- Show
- Registered codes only
Example result
| Code | Name | Class | What it means | Sent by | Cacheable by default | Would a retry help? (general guidance) | Key headers | Defined in | Common mistake |
|---|---|---|---|---|---|---|---|---|---|
| 300 | Multiple Choices | 3xx Redirection | More than one representation exists and the response lists them so the client can choose. | Server, redirection | Yes | Follow a choice (see Location) instead of repeating the request. | Location (the preferred choice, if any) | RFC 9110, Section 15.4.1 | No standard format exists for the list, so clients seldom choose automatically. |
| 301 | Moved Permanently | 3xx Redirection | The resource has a new permanent URI. Use it from now on. | Server, redirection | Yes | Follow the redirect (see Location); do not repeat the original request. | Location | RFC 9110, Section 15.4.2 | Clients may change POST to GET when they follow it. Use 308 to keep the method. Because it is cacheable, test a new redirect with a temporary code first. |
| 302 | Found | 3xx Redirection | The resource is temporarily at another URI. Keep using the original URI for later requests. | Server, redirection | No | Follow the redirect (see Location); do not repeat the original request. | Location | RFC 9110, Section 15.4.3 | For historical reasons a client may change POST to GET. Use 307 to keep the method or 303 to ask for a GET. |
| 303 | See Other | 3xx Redirection | The result is at another URI, which the client fetches with GET (or HEAD). It is mainly used to answer a POST. | Server, redirection | No | Follow the redirect with GET; do not repeat the POST. | Location | RFC 9110, Section 15.4.4 | The new URI is not the same resource. Do not use 303 for pages that have moved. |
| 304 | Not Modified | 3xx Redirection | A conditional GET or HEAD found the client’s stored copy still valid, so no body is sent. | Server (or a cache validating a stored response) | No | Use the stored copy. | ETag, Cache-Control, Expires, Vary, Content-Location, Date | RFC 9110, Section 15.4.5 | It answers only conditional GET or HEAD requests, has no body, and must repeat the cache headers a 200 would carry. |
IANA registry last updated 2025-09-15. Explanations are written for this page from RFC 9110 section 15 and the RFCs named in each row. “Cacheable by default” means heuristically cacheable under RFC 9110 section 15.1 (any response can be cached when it carries explicit freshness headers). The retry column is general guidance, not a protocol rule.