HTTP Status Codes Explained: The Five Classes, 418, 451, and 402

Tim Berners-Lee's early HTTP, later called HTTP/0.9, was extremely small. A request consisted of a line such as GET /path. The response had no headers and no status line; it returned only a body.

RFC 1945 describes the older response form with this grammar:

Simple-Response = [ Entity-Body ]

Without a status line, a client could not distinguish success, redirection, conditional responses, and failures through the machine-readable contract used by modern HTTP. A body could explain a problem to a person, but it did not provide the current protocol structure.

Three-digit HTTP status codes did not first appear in RFC 1945. W3C documents from 1992 already describe three-digit codes and response classes, while a historical design note explicitly points to FTP's three-figure status codes as an example.

RFC 1945, written by Tim Berners-Lee, Roy Fielding, and Henrik Frystyk and published in May 1996, documented HTTP/1.0 and defined a response's first line as the Status-Line:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Example: HTTP/1.0 200 OK

RFC 1945 documented the three-digit format and classification by the first digit. The practical advantage remains important: a recipient can determine an unfamiliar response's broad class from its first digit.

HTTP/1.0 documented 15 codes: 200, 201, 202, 204, 301, 302, 304, 400, 401, 403, 404, 500, 501, 502, and 503. Every one of those numbers remains listed in the current IANA HTTP Status Code Registry.

RFC 9110 §15 defines five classes according to the first digit:

The design supports forward compatibility. Under RFC 9110 §15, a client that does not recognize a status code treats it as equivalent to the x00 member of the same class. New codes can therefore communicate their broad outcome to older clients even when those clients do not understand the code's specific semantics.

An unfamiliar status code does not, by itself, prohibit cache storage. Storage is governed separately by RFC 9111 §3. An unfamiliar code can be stored when explicit response directives such as max-age and all other applicable conditions permit it, including no-store and shared-cache restrictions. For responses carrying must-understand, or with status 206 or 304, the cache must understand the status code. Recognizing a class is not unconditional permission to store or reuse a response.

The 2022 revision is especially significant. RFC 9110 is not merely an HTTP/1.1 document: it defines HTTP semantics shared by HTTP/1.1, HTTP/2, and HTTP/3. The transport and framing can change while status-code meanings remain common.

418 I'm a teapot appeared in RFC 2324 on April 1, 1998. RFC 2324 is an Informational RFC, not an Internet Standard. It describes the fictional Hyper Text Coffee Pot Control Protocol, or HTCPCP.

The joke says that a teapot asked to brew coffee returns 418 I'm a teapot. The historical phrase is widely recognized, but the current IANA registry and RFC 9110 §15.5.19 label 418 as “(Unused)”. New HTTP implementations should not assign it an application meaning merely because the earlier joke exists.

451 Unavailable For Legal Reasons was defined by RFC 7725 in February 2016 for cases where access to a resource is denied as a consequence of a legal demand.

The number refers to Ray Bradbury's novel Fahrenheit 451. RFC 7725's acknowledgements thank Terence Eden for suggesting a new status code and express gratitude to Ray Bradbury. Tim Bray is the RFC's author.

The entity producing a 451 response need not be the origin server; an intermediary such as an ISP or search engine can generate it. The response can explain the party making the legal demand and the class of resources affected, helping distinguish legal blocking from an ordinary missing page or access-control error.

402 Payment Required already appeared in a W3C status-code document from 1992 and was later included in the first HTTP/1.1 specification, RFC 2068. RFC 9110 §15.5.3 still marks it “reserved for future use.” Despite its long history, HTTP does not define an interoperable payment workflow for the code.

An API can assign 402 a private meaning for a failed payment or subscription state, but that does not make the meaning an HTTP standard. If you use it, document the API-specific contract instead of assuming clients will infer one universal behavior.

103 Early Hints was defined in the Experimental RFC 8297 in December 2017. It lets a server send selected hints before the final response is ready.

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </app.js>; rel=preload; as=script

(... the server prepares the final response ...)

HTTP/1.1 200 OK
Content-Type: text/html
...

A client can start processing the Link hints while the server prepares a final 200 OK. Intermediaries might not forward the informational response, and clients might ignore the hints, so correctness must never depend on receiving 103. Measure support and performance in the actual delivery path.

IANA maintains the official HTTP Status Code Registry.

When checked on September 3, 2026, the registry displayed a last-updated date of September 15, 2025 and contained 64 individually registered codes. Code 104 was a temporary registration expiring on November 13, 2026. Counts, expiration dates, and assignments can change, so implementations should consult the current registry and the specification referenced by each entry.

Products sometimes use unregistered numbers as private extensions, but those numbers have no standardized HTTP meaning. A conforming client can still classify an unknown code by its first digit, yet it cannot infer the extension's application-specific semantics.

• Early HTTP, later called HTTP/0.9, had no status line.
• Three-digit codes existed in 1992 W3C material before RFC 1945 documented 15 codes for HTTP/1.0.
• The five classes let recipients handle unfamiliar codes at a broad level.
• RFC 9110 defines semantics shared by HTTP/1.1, HTTP/2, and HTTP/3.
• 418 is “(Unused)” in the current registry; 451 reports legal obstacles; 402 remains reserved for future use.
• 103 Early Hints can send hints before a final response, but correctness cannot depend on it.