HTTP Status Codes Reference
Complete HTTP status codes reference with descriptions and RFC specs.
61 codes
The server has received the request headers and the client should proceed to send the request body.
The server agrees to switch protocols as requested by the client via the Upgrade header.
The server has received and is processing the request, but no response is available yet.
Used to return some response headers before the final HTTP message, allowing the client to preload resources.
The request succeeded. The meaning of success depends on the HTTP method used.
The request succeeded and a new resource was created. Typically used with POST or PUT.
The request has been accepted for processing, but processing has not been completed.
The returned metadata is not exactly the same as available from the origin server, but collected from a local or third-party copy.
The server successfully processed the request and is not returning any content.
The server successfully processed the request and asks the client to reset the document view.
The server is delivering only part of the resource due to a range header sent by the client.
The message body contains multiple separate response codes for multiple independent operations.
The members of a DAV binding have already been enumerated in a preceding part of the response.
The server has fulfilled a GET request and the response is a representation of the result of one or more instance-manipulations.
The request has more than one possible response. The user or user agent should choose one.
The URL of the requested resource has been changed permanently. The new URL is given in the response.
The URI of requested resource has been changed temporarily. Further changes in the URI might be made in the future.
The server sent this response to direct the client to get the requested resource at another URI with a GET request.
Used for caching. Tells the client that the response has not been modified, so the client can use the cached version.
The server sends this response to direct the client to get the requested resource at another URI with the same method.
The resource is now permanently located at another URI. Similar to 301 but the request method must not change.
The server cannot or will not process the request due to a client error such as malformed syntax.
The client must authenticate itself to get the requested response. Similar to 403 but authentication is possible.
Reserved for future use. Originally intended for digital payment systems.
The client does not have access rights to the content. Unlike 401, the client's identity is known to the server.
The server cannot find the requested resource. The URL is not recognized or the resource does not exist.
The request method is known by the server but is not supported by the target resource.
The server cannot produce a response matching the list of acceptable values defined in the request's headers.
Authentication is needed to be done by a proxy.
The server would like to shut down this unused connection. It is sent on an idle connection by some servers.
The request conflicts with the current state of the server, such as an edit conflict between multiple simultaneous updates.
The requested content has been permanently deleted from the server, with no forwarding address.
The server rejected the request because the Content-Length header field is not defined.
The client has indicated preconditions in its headers which the server does not meet.
The request entity is larger than limits defined by the server.
The URI requested by the client is longer than the server is willing to interpret.
The media format of the requested data is not supported by the server.
The range specified by the Range header field in the request cannot be fulfilled.
The expectation indicated by the Expect request header field cannot be met by the server.
The server refuses the attempt to brew coffee with a teapot. An April Fools' joke from RFC 2324.
The request was directed at a server that is not able to produce a response.
The request was well-formed but was unable to be followed due to semantic errors.
The resource that is being accessed is locked.
The request failed because it depended on another request and that request failed.
The server is unwilling to risk processing a request that might be replayed.
The server refuses to perform the request using the current protocol but might do so after the client upgrades.
The origin server requires the request to be conditional to prevent lost-update problems.
The user has sent too many requests in a given amount of time (rate limiting).
The server is unwilling to process the request because its header fields are too large.
The user agent requested a resource that cannot legally be provided, such as a web page censored by a government.
The server has encountered a situation it does not know how to handle.
The request method is not supported by the server and cannot be handled.
The server, while working as a gateway, got an invalid response from the upstream server.
The server is not ready to handle the request. Common causes are a server that is down for maintenance or overloaded.
The server is acting as a gateway and cannot get a response in time from the upstream server.
The HTTP version used in the request is not supported by the server.
The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself.
The method could not be performed on the resource because the server is unable to store the representation needed.
The server detected an infinite loop while processing the request.
Further extensions to the request are required for the server to fulfill it.
The client needs to authenticate to gain network access.
When an HTTP status code reference is the right tool
Use this page to look up what a status code means. Search or filter the bundled list — 61 codes with a name, a short description, and an RFC label. It will not send a request or change a response on a server.
Use cases
Checking a code you just saw in a log
Type 404, teapot, or a phrase such as rate limiting. Matching is a substring of the code, name, or description, and it is not case sensitive.
Browsing a class of responses
Use the 1xx–5xx buttons to limit the list to informational, success, redirection, client error, or server error codes. The color on each card follows that class.
What is on each card
The reason phrases and descriptions are English text stored in the app, not pulled from IANA at runtime. A few names use the RFC 9110 wording (for example 413 Content Too Large). The spec label is a citation, not a link.
What this tool does not do
It does not list every historical or unofficial code, and it does not probe a URL. To see what a live server returns, use HTTP Header Inspector or HTTP Request Builder. The reference stays in your browser.
How to use HTTP Status Codes Reference
- Optionally choose a 1xx–5xx filter, or leave it on All.
- Type a code, name, or wording in the search box if you want to narrow the list.
- Read the matching cards. An empty list shows that nothing matched.
Frequently asked questions
What does this HTTP status code reference include?
It ships 61 codes, grouped as 1xx, 2xx, 3xx, 4xx, and 5xx. Each card shows the numeric code, the reason phrase, a short English description, and a spec label such as RFC 9110. The list includes later or specialized codes such as 103, 226, 418, 425, and 451. It is a local lookup table, not a live request to a server.
How do search and the range filters work?
The search box matches a case-insensitive substring of the code, the name, or the description. The 1xx–5xx buttons keep codes whose first digit matches that class; clicking the active range again returns to All. The All label is hardcoded in English. The count above the list is the number of remaining cards.
Is this a complete list of every status code ever used?
No. Unofficial or rarely used codes, and some deprecated ones such as 305 and 306, are not listed. Names follow the current documents where they differ from older phrasing: 413 is Content Too Large and 422 is Unprocessable Content, both cited as RFC 9110 here.
Is anything fetched from the network?
No. The codes, descriptions, and RFC labels are bundled in the page. Filtering happens in your browser. This tool will not probe a URL or tell you what status your own server returns — use HTTP Header Inspector or HTTP Request Builder for that.
Related tools and guides
References
- Most everyday codes are defined in RFC 9110 (HTTP Semantics). Other cards cite the RFC shown on the row (for example RFC 8297 for 103, RFC 2324 for 418).
- This page’s descriptions are short summaries, not substitutes for the specification.