List HTTP status codes by category and reason phrase

The five supported categories are informational, success, redirect, client error, and server error, corresponding to the 1xx through 5xx classes. The result also identifies the numeric range and number of entries, making it useful for documentation, tests, developer tools, and quick protocol reference without sending a network request or inspecting a live server.

Choose one of the five HTTP response classes

HTTP status codes are grouped by their first digit. Informational responses occupy the 100–199 range and describe interim progress before a final response. Success responses use 200–299 and indicate that a request was received, understood, or completed in the way described by the particular code. Redirect responses use 300–399 for resource selection, changed locations, cache validation, and related routing decisions. Client errors use 400–499 when the request cannot be fulfilled because of its syntax, credentials, preconditions, target, rate, or another client-side condition. Server errors use 500–599 when the server or an intermediary cannot complete an apparently valid request. Supply one category name and the result returns its canonical name, numeric range, entry count, and an ascending `statuses` array. Category matching ignores letter case, surrounding whitespace, hyphens, and underscores, so `Client Error`, `client-error`, and `client_error` select the same class. Other labels are rejected clearly instead of being guessed.

Read codes and reason phrases accurately

Every array entry contains a numeric `code` and its standardized `reason_phrase`. The phrase is a concise conventional label, not a complete explanation of when a response should be generated. For example, 404 Not Found identifies the result, while the applicable HTTP specification defines cache behavior, method interactions, and representation semantics. Modern registry wording is used where older references may differ: 413 is Content Too Large and 422 is Unprocessable Content. Code 418 is included with the registry label Unused; the familiar teapot phrase comes from an earlier experimental specification and should not be treated as its current core registry title. Unassigned gaps are intentionally absent. That is why a category does not necessarily contain every integer within its numeric range. The list is sorted numerically, allowing callers to render tables directly, compare approved codes in a test, or construct a selector without another sorting pass. Reason phrases are descriptive metadata: HTTP/2 and HTTP/3 do not carry a reason-phrase field on the wire, and clients should make decisions from the numeric status code.

Use the result in documentation and validation

This capability works well when a tool needs a bounded reference set rather than details about one live response. A documentation generator can request each category and build consistent tables. A test harness can verify that an application emits a registered code in the expected class, while still applying its own rules about which specific responses an endpoint permits. An API explorer can populate a grouped menu with the returned reason phrases, and teaching material can contrast interim, successful, redirect, client-error, and server-error outcomes. The computation is a fixed in-memory lookup: it performs no network request, reads no server state, stores no input, and produces the same output for the same normalized category. It does not judge whether a code is appropriate for a particular business case, expand vendor-specific codes, or interpret a response body. Because registries can evolve as specifications add assignments, consumers that require a legally or operationally authoritative current registry should also retain the specification version used by their project. The browser and API share this deterministic solver; an API call costs $0.002.