This category indicates that the request has been received and is still being processed. It’s a provisional response, usually signaling that the server expects further action before completing the request.
Each of these categories contains specific status codes that provide more detail on the exact nature of the response.
1xx
- Informational #Informational 1xx
status codes indicate that the server has received the request and is continuing to process it, often requiring the client to wait for a final response.
Code | Name | Reference |
---|---|---|
100 | This interim response indicates that the client should continue the request or ignore the response if the request is already finished. | RFC9110, Section 15.2.1 |
101 | This code is sent in response to an Upgrade request header from the client and indicates the protocol the server is switching to. | RFC9110, Section 15.2.2 |
102 | This code indicates that the server has received and is processing the request, but no response is available yet. | RFC2518 |
103 | This status code is primarily intended to be used with the Link header, letting the user agent start preloading resources while the server prepares a response or preconnect to an origin from which the page will need resources. | RFC8297 |
104-199 |
2xx
- Success #Success 2xx
status codes indicate that the client’s request was successfully received, understood, and processed by the server.
Code | Name | Reference |
---|---|---|
200 | Depending on the HTTP method: | RFC9110, Section 15.3.1 |
201 | The request succeeded, and a new resource was created as a result. This is typically the response sent after | RFC9110, Section 15.3.2 |
202 | The request has been received but remains unprocessed, reflecting a noncommittal status since HTTP does not allow for asynchronous responses to indicate the request's outcome. This status is designed for situations where another process or server manages the request, or for batch processing scenarios. | RFC9110, Section 15.3.3 |
203 | This response code indicates that the returned metadata differs slightly from what is available on the origin server, as it has been sourced from a local or third-party copy. It is primarily used for mirrors or backups of other resources; otherwise, the | RFC9110, Section 15.3.4 |
204 | There is no content to send for this request, but the headers may provide useful information. The user agent may update its cached headers for this resource with the new ones provided. | RFC9110, Section 15.3.5 |
205 | Tells the user agent to reset the document which sent this request. | RFC9110, Section 15.3.6 |
206 | This response code is utilized when the client sends a | RFC9110, Section 15.3.7 |
207 | Conveys information about multiple resources, for situations where multiple status codes might be appropriate. | RFC4918 |
208 | Used inside a | RFC5842 |
209-225 | ||
226 | The server has successfully fulfilled a | RFC3229 |
227-299 |
3xx
- Redirection #Redirection 3xx
status codes indicate that further action is required by the client to complete the request, often involving a different resource or URL.
Code | Name | Reference |
---|---|---|
300 | The request has multiple possible responses, and the user agent or user should select one of them. While there is no standardized method for making this selection, it is recommended to provide HTML links to the available options so the user can choose. | RFC9110, Section 15.4.1 |
301 | The URL of the requested resource has been changed permanently. The new URL is given in the response. | RFC9110, Section 15.4.2 |
302 | The URI of the requested resource has been temporarily changed, with the possibility of further changes in the future. As a result, the client should continue to use the same URI for future requests. | RFC9110, Section 15.4.3 |
303 | The server sent this response to direct the client to get the requested resource at another URI with a | RFC9110, Section 15.4.4 |
304 | This is used for caching purposes, informing the client that the response has not been modified, allowing the client to continue using the same cached version of the response. | RFC9110, Section 15.4.5 |
305 | The status code was defined in a previous version of the specification and is now deprecated. | RFC9110, Section 15.4.6 |
306 | Originally defined in an earlier version of the HTTP specification, this status indicated that a requested response must be accessed through a proxy. It has been deprecated due to security concerns related to the in-band configuration of proxies. | RFC9110, Section 15.4.7 |
307 | The server sends this response to direct the client to get the requested resource at another URI with the same method that was used in the prior request. This has the same semantics as the | RFC9110, Section 15.4.8 |
308 | The permanent redirect status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. | RFC9110, Section 15.4.9 |
309-399 |
4xx
- Client Errors #Error 4xx
status codes indicate that the client made an invalid request, resulting in the server being unable to process it, often due to issues like missing resources or incorrect data.
Code | Name | Reference |
---|---|---|
400 | The server cannot or will not process the request because it is perceived as a client error, such as malformed request syntax, invalid request message framing, or deceptive request routing. | RFC9110, Section 15.5.1 |
401 | While the HTTP standard specifies "unauthorized," this response semantically means "unauthenticated," indicating that the client must authenticate itself to receive the requested response. | RFC9110, Section 15.5.2 |
402 | This response code is reserved for future use. Originally intended for digital payment systems, it is rarely utilized, and no standard convention currently exists for its application. | RFC9110, Section 15.5.3 |
403 | The client lacks access rights to the content, meaning it is unauthorized, and the server is refusing to provide the requested resource. Unlike the | RFC9110, Section 15.5.4 |
404 | The server cannot find the requested resource. In a browser, this indicates that the URL is unrecognized, while in an API, it may signify that the endpoint is valid but the specific resource does not exist. Servers may also use this response instead of a | RFC9110, Section 15.5.5 |
405 | The request method is recognized by the server but is not supported by the target resource. For instance, an API may not permit the use of | RFC9110, Section 15.5.6 |
406 | This response is sent when the web server, after conducting server-driven content negotiation, fails to find any content that meets the criteria specified by the user agent. | RFC9110, Section 15.5.7 |
407 | This is similar to | RFC9110, Section 15.5.8 |
408 | This response is sent by some servers on an idle connection, even in the absence of any prior request from the client, indicating that the server intends to close the unused connection. Some servers may simply terminate the connection without sending this message. | RFC9110, Section 15.5.9 |
409 | This response is sent when a request conflicts with the current state of the server. | RFC9110, Section 15.5.10 |
410 | This response is sent when the requested content has been permanently deleted from the server, without any forwarding address. Clients are expected to remove their caches and links to the resource. The HTTP specification designates this status code for use with "limited-time, promotional services." | RFC9110, Section 15.5.11 |
411 | Server rejected the request because the | RFC9110, Section 15.5.12 |
412 | The client has indicated preconditions in its headers which the server does not meet. | RFC9110, Section 15.5.13 |
413 | The requested payload is larger than the limits set by the server. The server may either close the connection or return a | RFC9110, Section 15.5.14 |
414 | The URI requested by the client exceeds the length that the server is willing to process. | RFC9110, Section 15.5.15 |
415 | The server does not support the media format of the requested data, resulting in the rejection of the request. | RFC9110, Section 15.5.16 |
416 | The range specified by the | RFC9110, Section 15.5.17 |
417 | This response code indicates that the server cannot fulfill the expectation specified by the | RFC9110, Section 15.5.18 |
418 | Known as the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) which used to state that the server refuses the attempt to brew coffee with a teapot. The status code was an April 1 RFC that lampooned the various ways HTTP was abused; one such abuse was the definition of an application-specific 418 status code, which has been deployed as a joke often enough for the code to be unusable for any future use. | RFC9110, Section 15.5.19 |
419-420 | ||
421 | The request was directed to a server that is unable to generate a response. This may occur if the server is not configured to handle responses for the specific combination of scheme and authority present in the request URI. | RFC9110, Section 15.5.20 |
422 | The server recognizes the content type of the request (making a | RFC9110, Section 15.5.21 |
423 | The destination resource, or resource within the destination collection, was locked. | RFC4918 |
424 | The request failed due to failure of a previous request. | RFC4918 |
425 | Indicates that the server is reluctant to process a request that could potentially be replayed. | RFC8470 |
426 | The server refuses to fulfill the request using the current protocol but may be willing to do so if the client upgrades to a different protocol. The server includes an | RFC9110, Section 15.5.22 |
427 | ||
428 | The | RFC6585 |
429 | The | RFC6585 |
430 | ||
431 | Request Header Fields Too Large The | RFC6585 |
432-450 | ||
451 | This status code indicates that the server is denying access to the resource as a consequence of a legal demand. | RFC7725 |
452-499 |
5xx
- Server Errors #Server error 5xx
status codes indicate that the server encountered an error while processing a valid request, meaning the issue lies on the server side rather than with the client’s request.
Code | Name | Reference |
---|---|---|
500 | The server encountered an unexpected condition that prevented it from fulfilling the request. | RFC9110, Section 15.6.1 |
501 | The server does not support the functionality necessary to fulfill the request. This response is appropriate when the server does not recognize the request method and cannot support it for any resource. | RFC9110, Section 15.6.2 |
502 | This error response indicates that the server, acting as a gateway to obtain a necessary response for handling the request, received an invalid response. | RFC9110, Section 15.6.3 |
503 | The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. | RFC9110, Section 15.6.4 |
504 | While acting as a gateway or proxy, the server did not receive a timely response from an upstream server that it needed to access to complete the request. | RFC9110, Section 15.6.5 |
505 | The server does not support, or refuses to support, the major version of HTTP that was used in the request message. | RFC9110, Section 15.6.6 |
506 | The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process. | RFC2295 |
507 | The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. | RFC4918 |
508 | The server terminated an operation due to encountering an infinite loop while processing a request with "Depth: infinity." This status indicates that the entire operation has failed. | RFC5842 |
509 | ||
510 | The policy for accessing the resource has not been met in the request. The server should send back all the information necessary for the client to issue an extended request. | RFC2774 |
511 | Network Authentication Required The | RFC6585 |
512-599 |
The response status codes are defined in Request for Comments (RFCs) by the members of the Internet Engineering Task Force (IETF) and the HTTP Working Group (HTTPWG).
The HTTP status codes are published in the Hypertext Transfer Protocol (HTTP) Status Code Registry by Internet Assigned Numbers Authority (IANA).
Sources and recommended, further resources on the topic:
License: HTTP status codes by Jonas Jared Jacek is licensed under CC BY-SA 4.0.
This license requires that reusers give credit to the creator. It allows reusers to distribute, remix, adapt, and build upon the material in any medium or format, for noncommercial purposes only. To give credit, provide a link back to the original source, the author, and the license e.g. like this:
<p xmlns:cc="http://creativecommons.org/ns#" xmlns:dct="http://purl.org/dc/terms/"><a property="dct:title" rel="cc:attributionURL" href="https://www.ditig.com/publications/http-status-codes">HTTP status codes</a> by <a rel="cc:attributionURL dct:creator" property="cc:attributionName" href="https://www.j15k.com/">Jonas Jared Jacek</a> is licensed under <a href="https://creativecommons.org/licenses/by-sa/4.0/" target="_blank" rel="license noopener noreferrer">CC BY-SA 4.0</a>.</p>
For more information see the DITig legal page.