HTTP Status Explorer
Explains any HTTP status code — originating RFC, common causes, and related codes.
1xx — Informational
Provisional response — the request was received and processing continues.The client should continue sending the request body — used after the client sends an Expect: 100-continue header and the server confirms it will accept the request.
The server agrees to switch protocols, as requested in the client's Upgrade header — the base of the handshake that promotes an HTTP connection to WebSocket.
The server received and is processing the request, but no response is available yet — prevents the client from thinking the connection was lost during long WebDAV operations.
The server sends preliminary headers (e.g. Link to resources to preload) before the final response is ready, letting the browser start fetching resources earlier.
Signals that the server supports resuming a large interrupted upload from where it left off, instead of resending everything. Temporary IANA registration (since 2024, expected to expire on 2026-11-13) — not yet a published RFC, only an Internet-Draft.
2xx — Success
The request was received, understood, and accepted successfully.The request succeeded. The exact meaning of the response body depends on the method: for GET it's the requested resource, for POST it may be the result of the operation.
The request successfully created a new resource — the response typically includes a Location header pointing to the newly created resource.
The request was accepted for processing, but processing hasn't finished yet (and isn't guaranteed to finish) — typical of asynchronous queues.
The request succeeded, but the returned metadata came from a copy (e.g. proxy or cache) rather than directly from the origin server.
The request succeeded and there is no response body — common for DELETE or a PUT that only confirms the operation.
The request succeeded and the client should reset the form/document that originated the request.
The server is delivering only part of the requested resource, as indicated by the client's Range header — the basis of resumable downloads and video streaming.
The response carries the status of multiple independent operations, each with its own code — a WebDAV extension, used when a single request affects several resources.
The members of a WebDAV collection were already listed in a previous 207 response and won't be repeated.
The server fulfilled the request using one or more instance-manipulations (e.g. delta encoding) — a rarely used extension in practice.
3xx — Redirection
Further action is needed to complete the request, usually following another URL.More than one representation exists for the requested resource and the server has no clear preference — rarely used in practice, most APIs pick a default format.
The resource was permanently moved to a new URL — search engines transfer SEO value to the new address; browsers may switch the method to GET on the redirect.
The resource is temporarily at another URL. Historically ambiguous about preserving the original HTTP method — which is why 303 and 307 were introduced to remove that ambiguity.
Redirects the response to another URL always using GET, regardless of the original method — the mechanism behind Post/Redirect/Get, used to avoid form resubmission.
The resource hasn't changed since the client last fetched it (validated via If-None-Match/If-Modified-Since) — the client should use the cached copy, with no response body.
The resource can only be accessed through the proxy indicated in the Location header — deprecated due to security implications, most browsers never implemented it.
Reserved by the original HTTP/1.1 specification, never actually used — kept only so the number isn't reassigned.
Same as 302, but explicitly requires the client to repeat the request with the same method and body at the new URL — the unambiguous version of 302.
Same as 301, but explicitly requires the client to repeat the request with the same method and body — the unambiguous version of 301.
4xx — Client Error
The request contains bad syntax or cannot be fulfilled as sent.The server couldn't understand the request due to malformed syntax — invalid JSON, a parameter in the wrong format, a corrupted header.
The request requires authentication and the client didn't provide valid credentials — despite the name, it's about authentication (who you are), not authorization (what you're allowed to do).
Reserved for future use related to digital payment systems — today informally repurposed by some APIs to signal an exceeded plan/quota limit.
The server understood the request and recognizes the credentials, but refuses to authorize access — unlike 401, authenticating again doesn't help.
The server found no resource matching the URL — it doesn't say whether the resource never existed or was removed (that's what 410 is for).
The HTTP method used (e.g. DELETE) isn't supported for this resource — the response should include an Allow header listing the valid methods.
No representation of the resource satisfies the content negotiation criteria sent by the client (Accept, Accept-Language, etc.).
Same as 401, but the required authentication is for an intermediary proxy, not the destination server.
The server waited for the request longer than it was willing to and closed the connection.
The request conflicts with the current state of the resource — e.g. two concurrent edits to the same record, or an attempt to create a resource that already exists.
The resource existed but was permanently removed and there's no new address — unlike 404, it deliberately signals that the absence is final.
The server refuses the request because the Content-Length header wasn't provided.
A precondition sent via conditional headers (If-Match, If-Unmodified-Since) failed — common in optimistic updates, to avoid overwriting concurrent changes.
The request body is larger than the server is willing to process.
The request URL is longer than the server is willing to interpret.
The request body's format (Content-Type) isn't supported by the server for this resource/method.
The byte range requested in the Range header is outside the resource's bounds.
The server can't meet the expectation indicated in the request's Expect header.
The current IANA registry marks this code as "(Unused)" (RFC 9110 §15.5.19) — reserved, with no assigned meaning. Known as "I'm a Teapot", an April Fools' joke from 1998 (RFC 2324, the fictional HTCPCP protocol), but that name was never the registry's official state; a real HTTP server should never return it.
The request was directed at a server that can't produce a response — common in HTTP/2 when a connection is reused for a domain that shouldn't share it.
The request syntax is correct, but the server couldn't process the instructions it contains — e.g. well-formed JSON with a semantically invalid value.
The target resource is locked — a WebDAV extension.
The request failed because it depended on another operation that also failed — a WebDAV extension.
The server is unwilling to risk processing a request that might be replayed, sent during the TLS 0-RTT handshake.
The server refuses to complete the request using the current protocol and requires the client to switch protocols (see the Upgrade header).
The server requires the request to be conditional (e.g. include If-Match) to avoid the 'lost update' problem, where two concurrent edits silently overwrite each other.
The client sent too many requests in a given time window (rate limiting) — the response may include a Retry-After header saying when to try again.
The request headers, individually or combined, are too large for the server to process.
The resource can't be provided for legal reasons — e.g. content removed by court order or government blocking. The name references the novel 'Fahrenheit 451'.
A Laravel framework convention indicating the session's CSRF token has expired — not part of any RFC.
Informally used by the Twitter/X API for aggressive rate limiting, and by some Spring frameworks with the unrelated meaning 'Method Failure' — neither is standardized.
Returned by Internet Explorer when Windows Parental Controls block access to the page — Microsoft-specific, never became a web standard.
A convention used by some APIs (popularized by Esri/ArcGIS) to indicate an invalid or expired access token.
Logged by nginx internally when the client closes the connection before the server can respond — never actually sent to the client.
5xx — Server Error
The server failed to fulfill an apparently valid request.A generic error: something went wrong on the server and no more specific code applies — the starting point for any server-side log investigation.
The server doesn't recognize the request method or lacks the capability to fulfill it, for any resource.
The server, acting as a gateway or proxy, received an invalid response from the upstream server while trying to fulfill the request.
The server isn't ready to handle the request — usually temporary (overload or maintenance); may include Retry-After.
The server, acting as a gateway or proxy, didn't get a timely response from the upstream server.
The server doesn't support (or refuses to support) the HTTP protocol version used in the request.
A server misconfiguration in transparent content negotiation — the resource chosen as the variant is itself configured to negotiate, creating a loop.
The server couldn't complete the operation because it lacks storage space to represent the resource — a WebDAV extension.
The server detected an infinite loop while processing the request — a WebDAV extension, the successor to 507 for this specific scenario.
The current IANA registry marks this code as obsoleted ("Not Extended (OBSOLETED)") — it remains in the historical registry, but no longer represents an active protocol state. When in use, it signaled that further extensions to the request were required for the server to fulfill it.
The client needs to authenticate to gain network access — typical of public Wi-Fi captive portals.
A convention used by some hosting providers (popularized by Apache/cPanel) to indicate the account's bandwidth/transfer limit was exceeded.
The origin server returned an empty, corrupted, or unexpected response that Cloudflare couldn't interpret.
The origin server refused the connection from Cloudflare — the web server at the origin is down.
Cloudflare couldn't complete the TCP handshake with the origin server within the time limit.
Cloudflare couldn't route the request to the origin server — a DNS/network issue between Cloudflare and the origin.
Cloudflare connected to the origin server, but the origin didn't respond within the time limit before the connection was closed.
The TLS handshake between Cloudflare and the origin server failed.
The SSL certificate presented by the origin server is invalid, expired, or untrusted.
Informally used by some HTTP libraries and proxies to signal a network connection timeout — never standardized, its exact meaning varies by implementation.
The five HTTP status classes
Every HTTP status code has three digits, and the first digit defines its class: 1xx is informational, 2xx is success, 3xx is redirection, 4xx is a client error (something the requester needs to fix) and 5xx is a server error (something the server operator needs to fix). An HTTP client that doesn't recognize a specific code can still react reasonably just by looking at its class — which is why the specification guarantees the class never changes meaning, even as new codes are added.
Official and unofficial codes
Codes marked official are registered in the IANA HTTP Status Code Registry, the catalog maintained by the IETF that any conforming HTTP client or server must recognize. Several popular services (Cloudflare, nginx, Laravel, and others) also return their own, never-standardized codes to communicate situations the specification doesn't cover with enough granularity — Cloudflare, for instance, uses 520-526 to distinguish different kinds of failure when contacting the origin server, something a generic 502 wouldn't differentiate. This tool documents both groups side by side, always identifying which is which.
How to use this reference day to day
Search by the code number, a snippet of its name (e.g. 'not found'), or a word from its description (e.g. 'rate limit') — the search considers all three fields at once. Each expandable code shows its originating specification (when one exists), related codes (for comparison, e.g. the difference between 401 and 403), and a button to copy a ready-made status line (e.g. '404 Not Found'). A selected code is reflected in the URL — copy the link to share the explanation for a specific code.
Frequently asked questions
401 means the client isn't authenticated (or the credentials are invalid) — authenticating again might fix it. 403 means the client was identified but doesn't have permission for that action — authenticating again changes nothing.
They vary along two dimensions: whether the redirect is permanent (301/308) or temporary (302/307), and whether the client may switch the original HTTP method to GET (301/302) or must preserve it exactly (307/308). 303 is a separate case — it always forces GET, regardless of permanence.
Both say 'I couldn't find the resource', but 410 is a deliberate statement that the resource existed and was removed for good; 404 makes no such distinction — the resource may never have existed, may have moved, or the server may simply choose not to reveal why.
429 communicates that the client itself exceeded a rate limit — the problem is on its side. 503 communicates that the service as a whole is currently unavailable, for any client — the problem is on the server's side. Both may include a Retry-After header.
'I'm a Teapot' started as an April Fools' joke in 1998 (RFC 2324, the fictional HTCPCP protocol) and ended up staying in the current specification as a reserved code — it should never be returned by a real server, but frameworks occasionally use it as an easter egg.
Because they were never registered in the IANA HTTP Status Code Registry — they're conventions from specific services (Cloudflare, nginx, Laravel, etc.). A generic HTTP client has no obligation to recognize them; this tool documents them because they show up in practice, not because they're part of the standard.