Tip: Use Ctrl+F for quick navigation
| Http Status Code | Meaning of Status Code |
|---|---|
| 100 | The client should continue with its request. This temporary response is used to inform the client that part of its request has been received by the server and has not yet been rejected. The client should continue to send the remainder of the request or, if the request has been completed, ignore this response. After the request has been completed, the server must send a final response to the client. |
| 101 | The server has understood the client's request and will notify the client through the Upgrade message header to switch to a different protocol to complete the request. After sending this response's final blank line, the server will switch to those protocols defined in the Upgrade message header. Such measures should only be taken when switching to a new protocol is advantageous. For example, switching to a new HTTP version is more advantageous than an old version, or switching to a real-time and synchronous protocol to transmit resources using such features. |
| 102 | An extension status code from WebDAV (RFC 2518), representing that processing will be continued. |
| 200 | The request has succeeded, and the requested information or response headers will be returned with this response. |
| 201 | The request has been fulfilled, and a new resource has been created according to the request's needs, and its URI has been returned along with the Location header information. If the required resource cannot be created promptly, '202 Accepted' should be returned. |
| 202 | The server has accepted the request but has not yet processed it. As it may be rejected as it may be, the final request may or may not be executed. In the case of asynchronous operations, there is no better way than sending this status code. The purpose of the response with the returned 202 status code is to allow the server to accept requests for other processes (such as a batch operation that runs only once a day) without having to keep the client connected to the server until the batch operation is complete. The response that accepts the request processing and returns a 202 status code should include in the returned entity some indication of the processing current state, as well as a pointer to the status monitor or prediction of the state so that the user can estimate whether the operation has been completed. |
| 203 | The server has successfully processed the request, but the entity header information returned is not a valid set determined by the original server but a copy from a local or third-party. The current information may be a subset or superset of the metadata that caused the original server to know the super information. Using this status code is not mandatory and is only appropriate when the response does not return the 200 OK status code. |
| 204 | The server has successfully processed the request but does not need to return any entity content and expects to return updated metadata. The response may return new or updated metadata in the form of entity headers. If these headers exist, they should correspond to the requested variables. If the client is a browser, the user's browser should keep the page that sent the request without generating any changes in the document view, even if according to the specification the new or updated metadata should be applied to the user's browser activity view in the document. Because the 204 response is prohibited from including any message body, it always ends with the first empty line after the message header. |
| 205 | The server has successfully processed the request and has not returned any content. However, unlike the 204 response, the response returned by this status code requires the requester to reset the document view. This response is mainly used to accept user input and immediately reset the form so that users can easily start another input. Like the 204 response, this response is also prohibited from containing any message body and ends with the first empty line after the message header. |
| 206 | The server has fulfilled a partial GET request. Similar to HTTP downloading tools like FlashGet or Thunder, this response is used to implement resuming downloads (byte serving) or splitting a large document into multiple segments for simultaneous downloading. The request must include a Range header indicating the desired range of content, and may include an If-Range header as a precondition. The response must include the following header fields: Content-Range indicating the range of content returned in the response; for multipart/byteranges types, each multipart segment must include a Content-Range field indicating the segment's range. If the response includes a Content-Length, its value must match the actual byte range returned. Also, include Date, ETag, and/or Content-Location headers if they would have been returned in a 200 response to the same request. Include Expires, Cache-Control, and/or Vary headers if their values may differ from those sent previously for the same variant. If the If-Range request header is used for strong cache validation, the response must not include other entity headers; if weak cache validation is used, the response must not include other entity headers, preventing inconsistency between cached entity content and updated entity headers. Otherwise, the response must include all entity header fields that would have been returned with a 200 response. If the ETag or Last-Modified headers do not match exactly, clients must not combine the content of a 206 response with any previously cached content that is inconsistent with the updated entity headers. Any cache that does not support Range and Content-Range headers must not cache the content returned in a 206 response. |
| 207 | The status code is used for responses from WebDAV (RFC 2518) extended, indicating that subsequent messages will contain XML messages and may contain a series of separate response codes depending on the number of previous sub-requests. |
| 300 | The requested resource has a series of choices and information about each can be selected and driven by the browser. Users or browsers can select a preferred address for redirection. Unless it's a HEAD request, the response should include an entity listing resource attributes and addresses so that users or browsers can select the most suitable redirection address. The format of this entity is determined by the Content-Type format. Browsers may automatically make the most appropriate selection based on the response format and their own capabilities. RFC 2616 does not specify how such automatic selection should be done. If the server itself has a preferred feedback selection, the URI for this feedback should be specified in Location. Browsers may use this Location value as the automatic redirect address. In addition, unless specifically specified, this response can also be cached. |
| 301 | The requested resource has been permanently moved to a new location, and future references to this resource should use one of the several URIs returned by this response. If possible, clients with link-editing capabilities should automatically change the address to the URI returned by the server. Unless specified otherwise, this response can also be cached. The new permanent URI should be returned in the Location field of the response. Unless it's a HEAD request, the response entity should include hyperlinks and brief descriptions pointing to the new URI. If this is not a GET or HEAD request, the browser should not automatically redirect unless confirmed by the user, as the request conditions may change. Note: For some browsers using HTTP/1.0, if they send a POST request and receive a 301 response, subsequent redirect requests will become GET requests. |
| 302 | The requested resource now temporarily responds to requests from a different URI. Since this redirection is temporary, clients should continue to send future requests to the original address. Only if specified in Cache-Control or Expires, this response can be cached. The new temporary URI should be returned in the Location field of the response. Unless it's a HEAD request, the response entity should include hyperlinks and brief descriptions pointing to the new URI. If this is not a GET or HEAD request, browsers should not automatically redirect, unless confirmed by the user, as the request conditions may change. Note: Although RFC 1945 and RFC 2068 do not allow clients to change the request method during redirection, many existing browsers treat a 302 response as a 303 response and use the GET method to access the URI specified in Location, ignoring the original request method. Status codes 303 and 307 were added to clarify the expected client response by the server. |
| 303 | The response to the current request can be found at another URI, and the client should use the GET method to access that resource. This method exists primarily to allow POST requests activated by scripts to redirect output to a new resource. This new URI is not a substitute reference for the original resource. Meanwhile, the 303 response must not be cached. However, the second request (redirection) may be cached. The new URI should be returned in the Location field of the response. Unless it's a HEAD request, the response entity should include hyperlinks and brief descriptions pointing to the new URI. Note: Many HTTP/1.1 browsers before cannot correctly understand the 303 status. If interaction with these browsers needs to be considered, the 302 status code should suffice, as most browsers handle the 302 response the way clients should handle the 303 response as specified in the above specification. |
| 304 | If the client sends a conditional GET request and the request is allowed, and the content of the document (since last access or based on the requested conditions) has not changed, the server should return this status code. The 304 response must not include a message body, so it always ends with the first empty line after the message header. The response must include the following header information: Date, unless the server has no clock. If a server without a clock also follows these rules, the proxy server and client can add the Date field to the received response header (as specified in RFC 2068), and the caching mechanism will work normally. ETag and/or Content-Location, if the same request should return a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from those sent previously for the same variant. If the request for this response uses strong cache validation, the response must not include other entity headers; otherwise (for example, if a conditional GET request uses weak cache validation), the response must not include other entity headers, avoiding inconsistency between cached entity content and updated entity header information. If a 304 response indicates that the current entity is not cached, the caching system must ignore this response and resend a request without limiting conditions. If a 304 response requires updating a cached entry, the caching 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 will provide the URI information where the specified proxy is located, and the recipient needs to resend a separate request through this proxy to access the corresponding resource. Only the original server can establish a 305 response. Note: RFC 2068 does not explicitly specify that the 305 response is to redirect a single request and can only be established by the original server. Ignoring these restrictions may lead to serious security consequences. |
| 306 | In the latest specification, the 306 status code is no longer used. |
| 307 | The requested resource now temporarily responds to requests from a different URI. Since this redirection is temporary, clients should continue to send future requests to the original address. Only if specified in Cache-Control or Expires, this response can be cached. The new temporary URI should be returned in the Location field of the response. Unless it's a HEAD request, the response entity should include hyperlinks and brief descriptions pointing to the new URI. Because some browsers cannot recognize the 307 response, the necessary information mentioned above needs to be added so that users can understand and send access requests to the new URI. If this is not a GET or HEAD request, browsers should not automatically redirect unless confirmed by the user, as the request conditions may change. |
| 400 | 1. The request has semantic errors and cannot be understood by the server. Clients should not resubmit this request unless modified. 2. The request parameters are incorrect. |
| 401 | The current request requires user authentication. This response must include a WWW-Authenticate information header applicable to the requested resource to inquire about user information. Clients can resubmit a request containing appropriate Authorization header information. If the current request already includes an Authorization certificate, the 401 response indicates that server authentication has rejected those certificates. If the 401 response contains the same authentication request as the previous response and the browser has already attempted verification at least once, the browser should display the entity information contained in the response because this entity information may contain related diagnostic information. See RFC 2617. |
| 402 | This status code is reserved for future needs. |
| 403 | The server understood the request, but refuses to authorize it. Unlike a 401 response, authentication will not help, and the request should not be repeated. If this is not a HEAD request and the server wishes to explain why the request cannot be executed, it should include the reason for the refusal in the entity. Of course, the server may also return a 404 response if it does not want the client to obtain any information. |
| 404 | The request failed because the resource requested is not found on the server. No information is available to indicate whether this condition is temporary or permanent. If the server knows the situation, it should use the 410 status code to inform the client that the old resource is permanently unavailable and there is no forwarding address. The 404 status code is widely used when the server does not want to reveal why the request was refused or if there is no other suitable response available. |
| 405 | The method specified in the request line is not allowed for the resource identified by the request. The response must include an Allow header containing a list of valid methods for the resource. PUT and DELETE methods typically require special permissions on the server and are often not allowed by default, resulting in a 405 error. |
| 406 | The resource identified by the request is not capable of generating a response that is acceptable according to the Accept headers sent in the request. Unless this is a HEAD request, the response should include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The format of the entity is determined by the media type given in the Content-Type header. |
| 407 | Similar to the 401 response, but indicates that the client must first authenticate itself with the proxy. The proxy must return a Proxy-Authenticate header field containing a challenge applicable to the proxy for the requested resource. The client may repeat the request with a Proxy-Authorization header field containing the credentials. |
| 408 | The server timed out waiting for the request. The client did not produce a request within the time that the server was prepared to wait. The client may repeat the request without modifications at any time. |
| 409 | The request could not be completed due to a conflict with the current state of the target resource. This code is only allowed in situations where the user might be able to resolve the conflict and resubmit the request. The response should contain enough information for the user to recognize the source of the conflict. Conflicts are most likely to occur in response to a PUT request. For example, if versioning is being used and the request attempts to update an existing resource with an older version than the one currently in use, a 409 conflict error will be returned. |
| 410 | The target resource is no longer available at the origin server and this condition is likely to be permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the 404 status code should be used instead. This response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally 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 associated with the server's site. |
| 411 | The server refuses to accept the request without a defined Content-Length header. The client may repeat the request if it adds a valid Content-Length header field indicating the length of the message body in the request. |
| 412 | The server does not meet one of the preconditions that the requester put on the request header fields. This response allows the client to place preconditions on the current resource's state (its current headers) and thus prevent the requested method from being applied to a resource other than the one intended. |
| 413 | The server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server may close the connection to prevent the client from continuing the request. If the condition is temporary, the server should include a Retry-After header field to indicate that it is temporary and after what time the client may try again. |
| 414 | The server is refusing to service the request because the request-target (URI) is longer than the server is willing to interpret. This rare condition is likely to occur when a client improperly converts a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit potential security holes. Servers should return 414 if the URI is excessively long to prevent buffer overflow attacks. |
| 415 | The origin server is refusing to service the request because the payload is in a format not supported by this method on the target resource. The format problem might be the result of the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly. |
| 416 | If the request includes a Range header field, and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request did not specify an If-Range header field, then the server should return a 416 status code. If the range specified is outside the size of the resource, the response should include a Content-Range header field specifying the current length of the resource. The server should not use multipart/byteranges for the response content type. |
| 417 | The expectation given in the request's Expect header field could not be met by the server, or if the server is a proxy, it has evidence that the next-hop server could not meet the request's expectation. |
| 421 | The number of connections from the client to the server exceeds the server's capacity limit. Typically, the IP address seen by the server is the client's IP address (e.g., a gateway or proxy address). This situation may involve multiple end users. |
| 422 | The request was well-formed but was unable to be followed due to semantic errors. (RFC 4918 WebDAV) |
| 423 | The resource that is being accessed is locked. (RFC 4918 WebDAV) |
| 424 | The request failed due to failure of a previous request (e.g., a PROPPATCH request). (RFC 4918 WebDAV) |
| 425 | Defined in drafts of "WebDAV Advanced Collections Protocol", but not present in "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol" (RFC 3658). |
| 426 | The client should switch to a different protocol such as TLS/1.0. (RFC 2817) |
| 449 | A Microsoft extension. The request should be retried after performing the appropriate action. |
| 500 | The server encountered an unexpected condition that prevented it from fulfilling the request. Generally, this indicates an error in the server's code. |
| 501 | The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is unable to support it for any resource. |
| 502 | The server, while acting as a gateway or proxy, received an invalid response from the upstream server. |
| 503 | The server is currently unable to handle the request due to temporary overloading or maintenance of the server. This condition is temporary and will be alleviated after some delay. If known, the length of the delay may be indicated in a Retry-After header. If no Retry-After is given, the client should handle the response as it would for a 500 status code. Note: The presence of a 503 status code does not imply that a server must use it when overloaded. Some servers may simply refuse the connection. |
| 504 | The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server (e.g., HTTP, FTP, LDAP) or auxiliary server (e.g., DNS) needed to complete the request. Note: Some proxy servers may return a 400 or 500 error in response to a DNS timeout. |
| 505 | The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. This implies that the server is unable or unwilling to use the same protocol version as the client. The response should contain an entity describing why the version is not supported and what protocols are supported by the server. |
| 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. (RFC 2295) |
| 507 | The server is unable to store the representation needed to complete the request. This condition is considered temporary. (WebDAV - RFC 4918) |
| 509 | The server has exceeded the bandwidth limit. This is not an official status code, but it is still widely used. |
| 510 | The policy for accessing the resource has not been met. (RFC 2774) |
Our HTTP Status Codes and Explanations tool serves as a comprehensive reference for understanding the various HTTP status codes used in web communication. HTTP status codes indicate the outcome of HTTP requests and responses, providing crucial information for developers, system administrators, and SEO specialists.
Using our HTTP Status Codes and Explanations tool is straightforward:
Key features of our HTTP Status Codes and Explanations tool include:
Whether you're resolving website errors, optimizing SEO, or enhancing web functionality, our HTTP Status Codes and Explanations tool provides essential information and resources.
Links: google