Tip: Ctrl+F for quick search| Http status code | Status code meaning |
|---|---|
| 100 | The client should continue sending the request. This temporary response notifies the client that part of its request has been received by the server and has not been rejected. The client should continue sending the rest of the request, or, if the request is complete, ignore this response. The server must send the client a final response once the request is complete. |
| 101 | The server has understood the client's request and will use the Upgrade header to notify the client to complete this request with a different protocol. After sending the final empty line of this response, the server will switch to the protocols defined in the Upgrade header. Such measures should only be taken when switching to a new protocol is actually advantageous, for example when a new HTTP version has advantages over the old one, or when switching to a real-time synchronous protocol to transfer resources that use such features. |
| 102 | A status code added by the WebDAV (RFC 2518) extension, meaning processing will continue. |
| 200 | The request succeeded; the response headers or data body desired by the request will be sent with this response. |
| 201 | The request has been fulfilled and a new resource has been created based on the request, with its URI returned in the Location header. If the requested resource cannot be created in time, '202 Accepted' should be returned. |
| 202 | The server has accepted the request but has not yet processed it. Like a possible rejection, the request may or may not ultimately be carried out. For asynchronous operations, there is no more convenient choice than sending this status code. The purpose of a 202 response is to allow the server to accept a request for another process (for example a batch operation that runs only once a day) without requiring the client to keep the connection open until the batch operation finishes. A response that accepts the request and returns status code 202 should include in the returned entity information indicating the current processing state, plus a pointer to a status monitor or status forecast, so the user can estimate whether the operation has completed. |
| 203 | The server successfully processed the request, but the returned entity header metadata is not a definitive set that is valid on the original server - it comes from a local or third-party copy. The current information may be a subset or a superset of the original version. For example, metadata contained in the resource may let the original server know a superset of the metadata. Using this status code is not mandatory, and is only appropriate when the response would otherwise return 200 OK. |
| 204 | The server successfully processed the request but does not need to return an entity body and wants to return updated meta information. The response may return new or updated meta information in the form of entity headers. If these headers exist, they should correspond to the variables requested. If the client is a browser, the user's browser should retain the page that sent the request without any change in the document view, even though, per the specification, new or updated meta information should be applied to the document in the browser's active view. Since a 204 response is forbidden to contain a message body, it always ends with the first empty line after the message headers. |
| 205 | The server successfully processed the request and returned no content. But unlike a 204 response, a response with this status code requires the requester to reset the document view. It is mainly used to reset the form immediately after user input is accepted, so the user can easily start another input. Like the 204 response, this response is also forbidden from containing any message body and ends with the first empty line after the message headers. |
| 206 | The server has successfully fulfilled a partial GET request. HTTP download tools such as FlashGet or Thunder use this type of response to implement resumable downloads, or to split a large document into multiple download segments for simultaneous download. The request must include the Range header field to indicate the range of content the client desires, and may include If-Range as a request condition. The response must include the following header fields: Content-Range to indicate the range of content returned in this response; for a multipart download with Content-Type of multipart/byteranges, each multipart section must include a Content-Range field to indicate the content range of that segment. If the response includes Content-Length, its value must match the actual byte count of the content range it returns. Date, ETag and/or Content-Location, if the same request would have returned a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from those of previous responses to the same variable. If this response's request used If-Range strong cache validation, then this response should not include other entity headers; if this response's request used If-Range weak cache validation, then this response must not include other entity headers; this prevents inconsistency between the cached entity content and updated entity header fields. Otherwise, this response should include all entity header fields that a 200 response would have returned. If the ETag or Last-Modified headers do not match exactly, the client cache must not combine the content returned by the 206 response with any previously cached content. Any cache that does not support the Range and Content-Range headers must not cache the content returned by a 206 response. |
| 207 | A status code extended by WebDAV (RFC 2518), indicating that the message body after it will be an XML message, possibly containing a set of independent response codes depending on the number of preceding subrequests. |
| 300 | The requested resource offers a set of selectable responses, each with its own specific address and browser-driven negotiation information. The user or browser can choose a preferred address to redirect to. Unless this is a HEAD request, the response should include an entity that is a list of the resource's characteristics and addresses, so the user or browser can select the most appropriate redirect address from it. The format of this entity is determined by the format defined by Content-Type. The browser may automatically make the best selection based on the response format and its own capabilities. Of course, the RFC 2616 specification does not define how such automatic selection should be performed. If the server itself has a preferred response choice, the Location field should indicate the URI of that choice; the browser may use this Location value as the address for automatic redirection. Additionally, unless otherwise specified, this response is cacheable. |
| 301 | The requested resource has been permanently moved to a new location, and any future references to this resource should use one of the URIs returned by this response. If possible, any client with link-editing functionality should automatically change the request address to the one fed back from the server. Unless otherwise specified, this response is cacheable. The new permanent URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should include a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser must not automatically perform the redirect unless the user confirms it, since the conditions of the request may change as a result. Note: for some browsers using the HTTP/1.0 protocol, when the POST request they sent receives a 301 response, the subsequent redirect request will become a GET request. |
| 302 | The requested resource is being temporarily served from a different URI. Since such a redirect is temporary, the client should continue to send future requests to the original address. This response is cacheable only if specified in Cache-Control or Expires. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should include a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser must not automatically perform the redirect unless the user confirms it, since the conditions of the request may change as a result. Note: although the RFC 1945 and RFC 2068 specifications do not allow the client to change the request method when redirecting, many existing browsers treat a 302 response as a 303 response and use GET to access the URI specified in the Location field, ignoring the original request method. Status codes 303 and 307 were added to clarify how the server expects the client to react. |
| 303 | The response to the current request can be found under a different URI and should be retrieved using GET on that resource. The existence of this method is mainly to allow the output of a POST request activated by a script to redirect to a new resource. The new URI is not a substitute reference for the original resource. Also, the 303 response must not be cached. Of course, the second request (the redirect) may be cacheable. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should include a hyperlink to the new URI and a short description. Note: many browsers predating HTTP/1.1 cannot correctly understand the 303 status. If interaction with these browsers needs to be considered, the 302 status code should suffice, since the way most browsers handle a 302 response is exactly what the specification above requires the client to do when handling a 303 response. |
| 304 | If the client has performed a conditional GET request and access is allowed, but the document's contents have not been modified since the last access or according to the conditions of the request, the server should return this status code. The 304 response must not contain a message body and therefore always ends after the first blank line following the headers. The response must include the following header fields: Date, unless the server has no clock. If a server without a clock also obeys these rules, proxy servers and clients can add the Date field to the received response headers themselves (as specified in RFC 2068), and the caching mechanism will work properly. ETag and/or Content-Location, if the same request would have returned a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from those of previous responses to the same variable. If this response's request used strong cache validation, then this response should not include other entity headers; otherwise (for example, if a conditional GET request used weak cache validation), this response must not include other entity headers; this prevents inconsistency between the cached entity content and updated entity header fields. If a 304 response indicates that a current entity is not cached, the cache system must ignore the response and repeat the request without conditions. If a 304 response is received that requires updating a cache entry, the cache system must update the entire entry to reflect the values of all fields updated in the response. |
| 305 | The requested resource must be accessed through the specified proxy. The Location field gives the URI information of the specified proxy, and the recipient needs to repeat a separate request through this proxy to access the resource. Only the origin server can create a 305 response. Note: RFC 2068 does not state clearly that a 305 response is meant for redirecting a single request and can only be created by the origin server. Ignoring these limits may lead to serious security consequences. |
| 306 | In the latest version of the specification, the 306 status code is no longer used. |
| 307 | The requested resource is being temporarily served from a different URI. Since such a redirect is temporary, the client should continue to send future requests to the original address. This response is cacheable only if specified in Cache-Control or Expires. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should include a hyperlink to the new URI and a short description. Because some browsers cannot recognize the 307 response, the necessary information above must be added so that the user can understand it and send a request to the new URI. If this is not a GET or HEAD request, the browser must not automatically perform the redirect unless the user confirms it, since the conditions of the request may change as a result. |
| 400 | 1. The request cannot be understood by the server due to malformed syntax. The client should not repeat the request without modifications. 2. The request parameters are invalid. |
| 401 | The current request requires user authentication. The response must include a WWW-Authenticate header field applicable to the requested resource to challenge for user information. The client may resubmit a request containing a suitable Authorization header field. If the current request already contained Authorization credentials, the 401 response means the server's validation has rejected those credentials. If a 401 response contains the same authentication challenge as a previous response and the browser has already attempted authentication at least once, the browser should display the entity information included in the response, since that entity information may contain relevant diagnostic information. See RFC 2617. |
| 402 | This status code is reserved for future needs. |
| 403 | The server understood the request but refuses to execute it. Unlike a 401 response, authentication provides no help, and the request should not be repeated. If this is not a HEAD request and the server wants to make clear why the request cannot be executed, the reason should be described in the entity. The server may also return a 404 response if it does not want the client to obtain any information. |
| 404 | The request failed; the resource the request wanted was not found on the server. No information can tell the user whether this condition is temporary or permanent. If the server knows the situation, it should use the 410 status code to indicate that the old resource is permanently unavailable for some internal configuration reason and has no forwarding address. The 404 status code is widely used when the server does not want to reveal why the request was refused or when no other suitable response is available. |
| 405 | The request method specified in the request line cannot be used to request the corresponding resource. This response must return an Allow header to list the request methods that the current resource accepts. Since PUT and DELETE methods perform write operations on resources on the server, most web servers either do not support these request methods or do not allow them in the default configuration, and such requests all return a 405 error. |
| 406 | The content characteristics of the requested resource cannot satisfy the conditions in the request headers, so no response entity can be generated. Unless this is a HEAD request, the response should return an entity containing a list of entity characteristics and addresses from which the user or browser can choose the most suitable one. The entity format is determined by the media type defined in the Content-Type header. The browser can make the best choice based on the format and its own capabilities, but the specification defines no standard for making such automatic selections. |
| 407 | Similar to the 401 response, except that the client must authenticate itself with the proxy server. The proxy server must return a Proxy-Authenticate to carry out the authentication challenge. The client can return a Proxy-Authorization header for authentication. See RFC 2617. |
| 408 | Request timeout. The client did not finish sending a request within the time the server was prepared to wait. The client can resubmit the request at any time without any changes. |
| 409 | The request could not be completed due to a conflict with the current state of the requested resource. This code may only be used in situations where the user is expected to be able to resolve the conflict and resubmit a new request. The response should include enough information for the user to discover the source of the conflict. Conflicts usually occur during the processing of PUT requests. For example, in an environment that uses version checking, if the version information attached to a PUT request modifying a specific resource conflicts with that of a previous (third-party) request, the server should return a 409 error to inform the user that the request cannot be completed. In this case, the response entity will likely include a comparison of the differences between the two conflicting versions, so the user can resubmit a new, merged version. |
| 410 | The requested resource is no longer available on the server and no forwarding address is known. This condition should be considered permanent. If possible, any client with link-editing functionality should, with the user's permission, remove all references to this address. If the server does not know or cannot determine whether the condition is permanent, the 404 status code should be used instead. Unless otherwise specified, this response is cacheable. The purpose of the 410 response is mainly to help webmasters maintain their sites by notifying users that the resource is no longer available and that the server owner wishes all remote links to this resource to be removed. This kind of situation is common with limited-time, value-added services. Likewise, the 410 response is used to inform the client that a resource that formerly belonged to an individual on the current server site is no longer available. Of course, whether all permanently unavailable resources should be marked as '410 Gone', and for how long that marking should be kept, is entirely up to the server owner. |
| 411 | The server refuses to accept the request without a defined Content-Length header. After adding a valid Content-Length header indicating the length of the request body, the client can resubmit the request. |
| 412 | The server could not meet one or more of the preconditions given in the request's header fields when it validated them. This status code lets a client set preconditions in the request's metadata (request header fields) before retrieving a resource, so as to avoid applying the request method to content other than the resource it intends. |
| 413 | The server refuses to process the current request because the size of the entity data submitted by the request exceeds the range the server is willing or able to process. In this situation the server may close the connection to keep the client from continuing to send this request. If the condition is temporary, the server should return a Retry-After response header to tell the client how long to wait before trying again. |
| 414 | The length of the request URI exceeds what the server is able to interpret, so the server refuses to serve the request. This is relatively rare; typical situations include: a form submission that should have used the POST method being turned into a GET method, resulting in an overly long query string (Query String). A redirect URI "black hole", for example, where each redirect appends the old URI as part of the new URI, causing the URI to become too long after several redirects. The client is attempting to attack the server by exploiting a security vulnerability present in certain servers. Such servers read or manipulate the request URI using a fixed-length buffer; when the parameters after GET exceed a certain value, a buffer overflow may occur, leading to arbitrary code being executed[1]. A server without such a vulnerability should return the 414 status code. |
| 415 | The entity submitted in the request is not in a format supported by the server for the requested method and resource, so the request is refused. |
| 416 | If the request included a Range request header, and none of the data ranges specified in the Range overlap the available range of the current resource, and the request also did not define an If-Range request header, the server should return the 416 status code. If the Range uses byte ranges, this situation means that the first-byte position of every data range specified in the request exceeds the length of the current resource. When returning the 416 status code, the server should also include a Content-Range entity header indicating the length of the current resource. This response is also prohibited from using multipart/byteranges as its Content-Type. |
| 417 | The expectation given in the Expect header of the request could not be met by the server, or the server is a proxy with clear evidence that the Expect content cannot be met at the next node along the current route. |
| 421 | The number of connections from the client's current IP address to the server exceeds the maximum allowed by the server. Usually the IP address here is the client address as seen by the server (for example the address of a user's gateway or proxy server). In this case the connection count may involve more than one end user. |
| 422 | The number of connections from the client's current IP address to the server exceeds the maximum allowed by the server. Usually the IP address here is the client address as seen by the server (for example the address of a user's gateway or proxy server). In this case the connection count may involve more than one end user. |
| 422 | The request is correctly formatted, but cannot be processed due to semantic errors. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV) |
| 424 | The current request failed because of an error in a previous request, for example PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Defined in the WebDav Advanced Collections draft, but does not appear in the WebDAV Ordered Collections Protocol (RFC 3658). |
| 426 | The client should switch to TLS/1.0. (RFC 2817) |
| 449 | Extended by Microsoft: the request should be retried after performing the appropriate action. |
| 500 | The server encountered an unexpected condition that prevented it from fulfilling the request. In general, this problem occurs when the server program code throws an error. |
| 501 | The server does not support the functionality required by the request. The request method is not recognized and cannot be supported for any resource. |
| 502 | The server, working as a gateway or proxy, received an invalid response from an upstream server while trying to execute the request. |
| 503 | Due to temporary server maintenance or overload, the server cannot process the request right now. This condition is temporary and will recover after some time. If the delay time can be predicted, the response may include a Retry-After header to indicate it. If no Retry-After information is given, the client should treat the response the way it treats a 500 response. Note: the existence of the 503 status code does not mean a server must use it when overloaded; some servers simply wish to refuse client connections. |
| 504 | A server working as a gateway or proxy did not receive a timely response from an upstream server (the server identified by the URI, e.g. HTTP, FTP, LDAP) or an auxiliary server (e.g. DNS) while trying to execute the request. Note: some proxy servers return a 400 or 500 error when a DNS query times out. |
| 505 | The server does not support or refuses to support the HTTP version used in the request. This implies that the server cannot or will not use the same version as the client. The response should include an entity describing why the version is not supported and which protocols the server supports. |
| 506 | Extended by the Transparent Content Negotiation protocol (RFC 2295): the server has an internal configuration error - the negotiated variant resource is configured to use itself in transparent content negotiation and therefore is not a proper choice within a negotiation. |
| 507 | The server cannot store the content needed to complete the request. This condition is considered temporary. WebDAV (RFC 4918) |
| 509 | The server reached its bandwidth limit. This is not an official status code, but it is still widely used. |
| 510 | The policy required to access the resource is not met. (RFC 2774) |
This tool belongs to the “Reference tables” category.
Your input is processed locally in the browser whenever possible. We do not store it.
Some lookups expose a JSON endpoint; the full list is on the Network Tools → API reference page.
Specifications evolve. These pages list the common entries and note the last update — report anything wrong.
We keep the high-frequency entries to hold page weight and load time down.