http HTTP Status Codes Reference star

Why Status Codes Are Grouped by First Digit

Every HTTP status code is a three-digit number, and the first digit alone tells a client the general category of the response before it even reads the rest — a design choice baked into HTTP from its earliest specifications and carried forward, formalized today in RFC 9110, the document that consolidated and superseded the older RFC 7230-7235 series to define HTTP's semantics independent of any single protocol version (HTTP/1.1, HTTP/2, HTTP/3 all share these same status code meanings). 1xx (Informational) means the request was received and understood and processing continues — these are provisional responses a client should not treat as final. 2xx (Success) means the request was received, understood, and accepted. 3xx (Redirection) means further action is needed to complete the request, typically fetching a different URL. 4xx (Client Error) means the request, as sent, contains a problem the client caused — bad syntax, missing authentication, a resource that does not exist. 5xx (Server Error) means the request was apparently valid but the server failed to fulfill it. This first-digit system means a client that recognizes only the digit "4" and nothing else about a specific code still knows, correctly, that something about its own request needs fixing rather than retrying identically — that fallback behavior is precisely why the standard mandates it.

The second and third digits subdivide each class into specific, documented meanings, and a client is expected to fall back to the general class behavior for any code it does not specifically recognize — this is why obscure or newer codes like 226 or 508 are still safe for older software to handle approximately correctly even without explicit support. Codes are also not invented freely: the full registry is maintained by IANA (the Internet Assigned Numbers Authority) precisely so that "599" or "250" cannot mean two different things on two different servers — every code in active use traces back to a specific RFC that defines its exact semantics, several of which extend the original HTTP/1.1 specification for particular protocols, most visibly WebDAV (RFC 4918), which is where the 207, 208, 422, 423, 424 and 507/508 codes on this page originate.

Two Codes Worth Knowing Precisely: 404 vs. 410

Two of the most commonly confused codes are 404 Not Found and 410 Gone, and the distinction is not cosmetic — it changes how a search engine and a browser behave. 404 is deliberately ambiguous: the server has no information about whether the resource ever existed at that URL, whether it might come back, or whether the URL was simply mistyped. 410 is a deliberate, stronger statement: the resource used to exist at that exact URL and has been intentionally, permanently removed, with no forwarding address — RFC 9110 explicitly recommends 410 specifically for this "condition is likely to be permanent" case where a 404 would understate the certainty. Search engines treat this differently in practice: a URL returning repeated 404s is typically dropped from the index only after being re-crawled several times over an extended period just in case it comes back, while a 410 signals intentional removal and search engines generally act on it faster, de-indexing the page sooner because the server has explicitly vouched that it will not return. Using 410 correctly when permanently retiring a page — rather than defaulting to 404 for everything — is a small but real technical SEO lever.

• 301 vs. 302 vs. 307 vs. 308: 301 and 308 both mean "permanently moved," while 302 and 307 both mean "temporarily moved" — the newer 307/308 pair was introduced specifically to guarantee the request method and body are preserved on redirect (a POST stays a POST), because widespread historical browser behavior silently converted 301/302 redirects to a GET, which broke form resubmission in ways the newer codes fix.
• 401 vs. 403: 401 Unauthorized technically means "you are not authenticated — log in," despite the confusing name; 403 Forbidden means "you are identified, but you are not allowed to access this," a distinction many APIs blur in practice but that the specification keeps clearly separate.
• 429 Too Many Requests (RFC 6585) is the standard rate-limiting response and is commonly paired with a Retry-After header telling the client exactly how long to wait before trying again.
• 1xx codes are rarely seen directly because most HTTP client libraries handle them transparently before your application code ever sees a response — 100 Continue, for instance, lets a client check whether a large request body is even worth sending before it sends it.