A bulk HTTP status codes reference is a standards-backed table of every individually registered response code, organized so you can scan, filter, and compare many entries at once. The HTTP Status Codes tool ships exactly 64 entries drawn from the IANA HTTP Status Code Registry, captured on July 17, 2026, and ordered by numeric code from 100 through 511. Each row includes the reason phrase, a concise meaning, a registration-state badge, and the RFC reference that governs its semantics, which is what makes the page a workable bulk reference instead of a hand-curated cheat sheet. Codes are grouped into five response classes by their first digit — 1xx Informational, 2xx Successful, 3xx Redirection, 4xx Client error, 5xx Server error — so filtering by class is the fastest way to scope a wide lookup. Because filtering and search run entirely in your browser and the text is never uploaded, you can paste internal reason phrases or RFC numbers without sending them off the page. Treat the snapshot date as material when evaluating temporary codes, since temporary registrations can change between IANA updates.
Scope of the bulk HTTP status codes reference
The table is registry-first: every row corresponds to one named entry currently present in the IANA HTTP Status Code Registry. The snapshot captures individually registered rows only, which means unassigned ranges and vendor-specific extensions are deliberately left out. Five classes are populated with representative values, boundaries, commonly used codes, sparse high values, unused entries, and the time-sensitive temporary 104 registration. Ordering is strictly ascending by number, codes are unique, and code-and-phrase pairs are unique, which is what you need when scanning the entire set at a glance. Each row carries the reason phrase as it appears in IANA, a short standards-aligned paraphrase in the meaning column, a registration-state label, and a link to the cited specification so you can move from the bulk view into the governing text.
How to look up HTTP status codes in bulk
- Open the HTTP Status Codes reference in your browser.
- Enter a search term — an exact three-digit code such as 404, a class pattern like 4xx, a reason phrase such as Not Found, a protocol term such as WebDAV, or an RFC reference.
- Choose a response class from the selector — Informational, Successful, Redirection, Client error, or Server error — when you want to limit the matching response class.
- Read the phrase, concise meaning, registration-state label, and RFC reference for each row that survives both filters.
- Click the linked RFC when implementation details affect caching, security, retry behavior, or method-dependent semantics.
The text query and class selector combine, so searching gateway while the Server error class is selected returns only gateway-related server failures, while searching Not Found under Server error produces an empty result rather than leaving a stale table visible. Exact numeric search is strict: entering 404 returns only 404 rather than every description that contains the digits 4, 0, and 4.
Search inputs that work across many entries
The reference is designed so a single query can pull a wide slice of the table, not just one row.
- Exact three-digit code — strict equality. Entering 429 returns only 429, not every row containing 4, 2, or 9.
- Class pattern — typing 4xx selects every individually registered client-error entry without fabricating rows for unassigned numbers inside the class.
- Reason phrase — searching Not Found or Too Many Requests matches the canonical text without raising similar rows by accident.
- Concept or protocol term — searching gateway pulls the gateway-related server failures across the 5xx range, and searching WebDAV pulls the WebDAV extension codes regardless of class.
- RFC reference — entering an RFC number lets you verify which codes are governed by which specification, which is useful when the registry has shifted between RFC 7231, RFC 7538, RFC 9110, and the WebDAV extensions.
No matching set is silently truncated, so when a query is too narrow the interface explains that no registered entry matched instead of leaving an outdated table visible.
Reading the state badges across the table
Registration state matters because a code can have an explicit row in IANA without being a safe current response. Five labels are surfaced across the bulk table.
- Current — codes that the current registry and RFC 9110 treat as ordinary, ongoing responses, including the high-traffic 200, 304, 404, and 500.
- Temporary — code 104, Upload Resumption Supported, is tied to an active Internet-Draft, so its state and snapshot date are surfaced explicitly because temporary registrations can expire or change.
- Deprecated — 305 Use Proxy is deprecated through RFC 9110 and keeps its row with a warning badge so it is not chosen as an ordinary current response.
- Unused — 306 and 418 are reserved and labeled unused in the registry; the familiar teapot phrase is intentionally not presented as the current description.
- Obsolete — 510 Not Extended is obsolete, kept visible because it has an explicit registry row but flagged so it is not picked as a working current code.
The state badges are what make a bulk reference honest: a deprecated or obsolete code still has a place in the table because it has a registry row, but the badge prevents it from being mistaken for an active response choice.
Entries the bulk reference leaves out, and why
The boundary between registered and unassigned is intentional. The table contains named individual entries in the IANA registry and excludes unassigned ranges and vendor-specific extensions, which prevents a framework-specific code from being presented as an Internet standard. A three-digit value can be syntactically shaped like an HTTP status code without appearing here, which is why an exact search for 105 returns no row: 105 currently sits inside an unassigned range, so the interface reports that no registered entry matched. Servers can emit non-standard codes that are not listed in this table, and the page does not pretend otherwise. The same boundary protects the temporary 104 row: because 104 has an explicit registry row labeled Temporary, it appears with the right state badge rather than being merged into a generic 1xx bucket or dropped as a vendor code.
Understanding vs. diagnosing an HTTP response
The table describes protocol outcomes, not operational causes. A 502 Bad Gateway can reflect an upstream crash, a network path problem, a proxy timeout policy, or malformed upstream output. A 429 response indicates rate limiting, but its retry behavior depends on the service and may use Retry-After. A 404 can conceal a forbidden resource, and a 500 is intentionally generic. Use server logs, request identifiers, response headers, and the relevant service documentation when diagnosing a live incident; this page does not contact a URL, inspect a server, or claim to identify an operational fault.
| Class | Range | Role | Representative entries |
|---|---|---|---|
| 1xx Informational | 100–199 | Interim progress before a final response | 100 Continue, 102 Processing, 103 Early Hints |
| 2xx Successful | 200–299 | Request accepted, understood, and processed | 200 OK, 201 Created, 204 No Content, 206 Partial Content |
| 3xx Redirection | 300–399 | Client must take additional action to fulfill the request | 301 Moved Permanently, 302 Found, 304 Not Modified, 307 Temporary Redirect |
| 4xx Client error | 400–499 | Condition attributed to the client request | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx Server error | 500–599 | Server-side failure or inability to fulfill a valid request | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout |
Within a class the codes communicate different things and usually require different remedies: 404 Not Found and 429 Too Many Requests are both client-error responses, but they signal different conditions and call for different responses on the client side. The reference includes method-dependent notes where they matter — 200 OK has method-dependent meaning, 204 No Content prohibits response content, 304 Not Modified participates in conditional caching, and 401 Unauthorized concerns missing or invalid authentication credentials despite its historical reason phrase — but for full semantics the cited RFC remains authoritative.
For readers who want a similar registry-first view through a different lens, the HTTP Status Codes Alternative: A Registry-First Lookup guide explains how the same snapshot is organized around the registry row itself. When you need to cross-check the table against an independent implementation-oriented source, the MDN HTTP response status codes page documents the same codes from a browser-implementation perspective, and the IANA HTTP Status Code Registry CSV is the source of truth for registration state.
If you're weighing options, Bulk JavaScript Playground Runs: Iterate Snippets Safely covers this in detail.