HTTP response status codes (or simply status codes) are three-digit codes issued by a server in response to a browser-side request from a client. These status codes serve as a means of quick and concise communication on how the server worked on and responded to the client’s request. These codes also include codes from IETF Request for Comments (RFCs), other specifications, and some additional codes used in common applications of the HTTP.
The Internet Assigned Numbers Authority (IANA) maintains the official registry of HTTP status codes. On the 3 digits of a HTTP status code, the first digit defines the category of the status code, while the last two digits are assigned for a specific type of response under a given category. There are five different categories of HTTP status codes, and they are classified based on the type of response the server communicates to the client:
- 1XX – Informational code: This category indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response. The message consists only of the status line and optional header fields, and is terminated by an empty line.
- 2XX – Success code: This category indicates the action requested by the client was received, understood, and accepted. This essentially means that the request that the client made was a good request, and that the server completed what it was supposed to do completely and successfully.
- 3XX – Redirection code: This category indicates that the client may take additional action to complete the request. Usually that additional action is to redirect the user to another URL. Many of the status codes in this category are used in URL redirection.
- 4XX – Client error code: This category indicates that request cannot be fulfilled because there is an error coming from the client. The request might contain bad syntax or lack of authorization, etc. The server should include an entity containing an explanation of the error situation (except when responding to a HEAD request), and whether it is a temporary or permanent condition.
- 5XX – Server error code:This category indicates that the server has encountered an error or is incapable of performing a valid request. The server should include an entity containing an explanation of the error situation (Except when responding to a HEAD request), and indicate whether it is a temporary or permanent condition.
Listed below are the most common HTTP response status codes for each category.
A. Informational codes
100 Continue
This status code indicates that everything is fine, and that the browser should continue with the request or ignore it if it is already finished.
This is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. Then, the browser should continue by sending the remainder of the request or, should ignore this response if the request has already been completed. The server must send a final response after the request has been completed. A browser must first include Expect: 100-continue in the request header in its initial request, in order to receive a 100 Continue status code in response before sending the body.
101 Switching Protocols
This status code indicates the server is willing to switch the application protocol used in the connection as requested by a browser via the Upgrade request header. The server will also include in the response an Upgrade response header to indicate the protocol it switched to.
The protocol can only be switched when it is advantageous to do so, e.g. switching to a newer version of HTTP over older versions, and switching to a real-time and synchronous protocol when delivering resources that need it.
103 Early Hints
This status code is used together with the Link header to allow the user-agent (e.g. browser) to start preloading resources while the server is still preparing a response.
B. Success codes
200 OK
This status code indicates that the request has succeeded. The meaning of a success depends on the HTTP request method:
- GET: The requested resource has been transmitted in the response together with the message body.
- HEAD: The representation headers are transmitted in the response without any message body.
- POST: The resource describing the result of the action is transmitted in the response.
- TRACE: The response contains the request message as received by the server.
The status code for successful result of PUT or DELETE is often not a 200 OK, but a 204 No Content, or a 201 Created if the resource is uploaded for the first time. A 200 response is cacheable by default.
201 Created
This status code indicates that the request has succeeded and has resulted in the creation of a new resource. The server will have to create the resource before returning the 201. The new resource is returned in the body of the message, and it can be located either at the URI of the request, or at the content of the Location header.
202 Accepted
This status code indicates that the request has been accepted for processing, and the processing has not been completed or started. The request may or may not be acted upon, as it might be disallowed when processing actually takes place.
202 status is non-committal. Its purpose is to allow a server to accept another request for another process (e.g. a batch-oriented process) without requiring the user agent’s connection to the server to persist until the process is completed. This means, there is no way for the HTTP to later send a status code indicating the outcome of processing the request. But, the response will include an indication of the request’s current status, and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
203 Non-Authoritative Information
This status code indicates that the request was successful but the enclosed payload has been modified by a transforming proxy from the origin server’s 200 OK response. And the returned metainformation in the header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. A 203 response is cacheable by default.
204 No Content
This status code indicates that a request has succeeded, but does not need to return a body, so that the client doesn’t need to navigate away from its current page. The 204 response doesn’t include a body, and thus is always terminated by the first empty line after the header field.
This response is intended to allow input for actions to take place without causing a change to the browser’s active page, although any new or updated metainformation will be applied to the browser’s active page. For example, when implementing “save and continue editing” functionality for a wiki site. In this case a PUT request would be used to save the page, and the 204 response would be sent to indicate that the editor should not be replaced by another page. A 204 response is cacheable by default (an ETag header is included in such a response).
C. Redirection codes
300 Multiple Choices
This status code indicates that the request has more than one possible response. The user-agent or the user should choose one of them. Unless it was a HEAD request, the response will include a list of resource characteristics and location(s) from which the user can choose from.
Depending upon the format and the capabilities of the browser, selection of the most appropriate choice can be performed automatically. If the server has a preferred choice of representation, it will include the specific URI for that representation in the Location field, and the browser can use the Location field value for automatic redirection. As there is no standardized way of choosing one of the responses, this response code is very rarely used. A 300 response is cacheable by default.
301 Moved Permanently
This status code indicates that the resource requested has been definitively moved to the new permanent URI. The permanent URI is given by the Location field in the response. If the request method was HEAD, the response will contain a short hypertext note with a hyperlink to the new URI(s). For request methods other than GET or HEAD, a 301 status code will not automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
It is recommended to use the 301 status code only as a response for GET or HEAD methods as the method change is explicitly prohibited with this status, and to use 308 Permanent Redirect for POST methods instead. A 301 response is cacheable by default.
302 Found
This status code indicates that the resource requested has been temporarily moved to the URI. The temporary URI is given by the Location field in the response. If the request method was HEAD, the response will contain a short hypertext note with a hyperlink to the new URI(s). For request methods other than GET or HEAD, a 302 status code will not automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
It is recommended to use the 302 code only as a response for GET or HEAD methods, as the method change is explicitly prohibited for this status, and to use 307 Temporary Redirect if the method is changed when the redirected request is made. In the cases where you want the method used to be changed to GET, use 303 See Other instead. This is also useful when you want to give a response to a PUT method that is not the uploaded resource but a confirmation message such as: ‘you successfully uploaded XYZ’. A 302 response is cacheable if indicated by a Cache-Control or Expires header field.
303 See Other
This status code indicates that the redirects don’t link to the newly uploaded resources, but to a custom page (e.g. confirmation page or upload progress page). This status code is usually sent back as a result of PUT or POST. The method used to display this redirected page is always GET.
304 Not Modified
This status code indicates that there is no need to retransmit the requested resources. It is an implicit redirection to a cached resource. This happens when the request method is safe, e.g. GET or HEAD, or when the request is conditional and uses a If-None-Match or a If-Modified-Since header. The equivalent 200 OK response would have included the headers Cache-Control, Content-Location, Date, ETag, Expires, and Vary.
307 Temporary Redirect
This status code indicates that the resource requested has been temporarily moved to the URI. The temporary URI is given by the Location field in the response. The only difference between 307 and 302 Found is that 307 guarantees that the method and the body will not be changed when the redirected request is made. For GET requests, 302 and 307 behavior is identical. The behavior with non-GET methods and 302 Found is then unpredictable on the Web, whereas the behavior with 307 is predictable.
In the cases where you want the method used to be changed to GET, use 303 See Other instead. This is also useful when you want to give an answer to a PUT method that is not the uploaded resources, but a confirmation message (like “You successfully uploaded XYZ”).
308 Permanent Redirect
This status code indicates that the resource requested has been definitively moved to the URI. The permanent URI is given by the Location field in the response. The request method and the body will not be altered, whereas 301 may incorrectly sometimes be changed to a GET method.
D. Client error codes
400 Bad Request
This status code indicates that the server cannot process the request due to an error on the client side, e.g. malformed request syntax, invalid request message framing, or deceptive request routing. The client is advised to not repeat the request unless modifications are made.
401 Unauthorized
This status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. This status is sent with a WWW-Authenticate header that contains information on how to authorize correctly. With this status code, it is possible to repeat the request by including authentication in order to access the target resource. This status is similar to 403, but in this case, authentication is possible.
402 Payment Required
This status code is a nonstandard client error and is reserved for future use. Originally it was created to enable digital cash or payment systems and would indicate that the request can not be processed until the client makes a payment. However, no standard use convention exists and different entities use it in different contexts.
403 Forbidden
This status code indicates that the server understood the request but refuses to authorize it.
This status is similar to 401 Unauthorized, but in this case, re-authenticating will make no difference, so there is no need to repeat the request. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource. For any request methods except HEAD, if the server wants the reason for the refusal to be available to the client, then 403 can be used. However, if the server does not want to make this information available, then 404 Not Found can be used instead.
404 Not Found
This status code indicates that the server can’t find anything matching the Request-URI. Links that lead to a 404 page are often called broken or dead links and can be subject to link rot. There is no indication on whether the condition is temporary or permanent. But if the server knows that the resource is permanently removed, then 410 Gone should be used instead of a 404 status. This status code is also commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable. A 404 response is cacheable by default.
405 Method Not Allowed
This status code indicates that the request method is known by the server but is not supported by the target resource. The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The server MUST generate an Allow header field containing a list of supported methods for the requested resource. A 405 response is cacheable by default.
408 Request Timeout
This status code indicates that the server would like to shut down this unused connection, because the request exceeded the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time. A server should send the “close” Connection header field in the response, since 408 implies that the server has decided to close the connection rather than continue waiting.
409 Conflict
This status code indicates a request cannot be completed because of a conflict with the current state of the target resource. This code is allowed in situations where it is expected that the client might be able to resolve the conflict and resubmit the request. Hence, the response body should include enough information for the client to recognize the source of the conflict.
This is most likely to occur in response to a PUT request. For example, you may get a 409 response when uploading a file which is older than the one already on the server resulting in a version control conflict. In this case, the response should contain a list of the differences between the two versions in a format defined by the response Content-Type.
410 Gone
This status code indicates that access to the target resource is no longer available permanently at the origin server and no forwarding address is known. If the server owner doesn’t know whether this condition would be temporary or permanent, then 404 should be used instead.
The 410 response is primarily intended to assist the task of web maintenance by notifying the client that the resource is intentionally made unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time promotional services, and for resources belonging to individuals no longer working at the server’s site. A 410 response is cacheable by default.
414 URI Too Long
This status code indicates that the server refuses to process the request because the Request-URI provided by the client is longer than the server is willing to interpret.
There are a few conditions when this might occur: a) when a client has improperly converted a POST request to a GET request with long query information, b) when the client has descended into a loop of redirection (for example, a redirected URI prefix that points to a suffix of itself), or c) when the server is under attack by a client attempting to exploit potential security holes. A 414 response is cacheable by default.
415 Unsupported Media Type
This status code indicates that the server refuses to accept the request because the payload format is in an unsupported format. The format problem might be due to the request’s indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.
418 I’m a teapot
This status code indicates that the server refuses to brew coffee because it is, permanently, a teapot. A combined coffee/tea pot that is temporarily out of coffee should instead return 503 Service Unavailable. This status code was defined in 1998 as one of the IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol. Some websites use this response for requests they do not wish to handle, such as automated queries, and an Nginx HTTP server uses this code to simulate goto-like behaviour in its configuration.
429 Too Many Requests
This status code indicates the user has sent too many requests in a given amount of time (“rate limiting”). The response representations can include details explaining the condition, and a Retry-After header indicating how long to wait before making a new request. However, when a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources hence, when it may be more appropriate to just drop connections, or take other steps.
E. Server error codes
500 Internal Server Error
This status code indicates that the server encountered an unexpected condition which prevented it from fulfilling the request. This error response is usually used as a generic “catch-all” response indicating that the server cannot find a better 5xx status code to respond. Sometimes, server administrators log error responses like the 500 status code with more details about the request to prevent the error from happening again in the future.
501 Not Implemented
This status code means that the server does not support the functionality required to fulfill the request. This status can also send a Retry-After header, telling the client when to check back to see if the functionality is supported by then. A 501 code is not something you can fix, but requires a fix by the web server you are trying to access.
This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. The only methods that servers are required to support are GET and HEAD and therefore that must not return 501. If the server does recognize the method, but intentionally does not support it, the appropriate response is 405 Method Not Allowed. A 501 response is cacheable by default, unless caching headers instruct otherwise.
502 Bad Gateway
This status code indicates that the server, while acting as a gateway or proxy, received an invalid response from the upstream server in attempting to fulfill the request. A 502 code is not something you can fix, but requires a fix by the web server or the proxies you are trying to get access through.
503 Service Unavailable
This status code indicates that the server is currently unavailable and is not ready to handle any request due to a temporary overloading or maintenance of the server. This response is used as a temporary measure which is expected to be alleviated after some time. Together with this response, the Retry-After header should contain the estimated time for the recovery of the service, and a user-friendly page explaining the problem should also be included. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 Internal Server Error response.
504 Gateway Timeout
This status code indicates that the server, while acting as a gateway or proxy, did not get a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) in attempting to fulfill the request. A 504 code is usually not something you can fix, but requires a fix by the web server or the proxies you are trying to get access through.