Interactive reference for HTTP status codes with detailed explanations and RFC references
32 codes found
The server has received the request headers and the client should proceed to send the request body.
The requester has asked the server to switch protocols and the server has agreed to do so.
The server has received and is processing the request, but no response is available yet.
Used to return some response headers before final HTTP message.
The request succeeded. The meaning depends on the HTTP method: GET (resource fetched), HEAD (headers only), POST (resource created), TRACE (message received).
The request succeeded and a new resource was created. The new resource is returned in the response body, and its URI in the Location header.
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon.
The server successfully processed the request and is not returning any content. Common after successful DELETE or PUT operations.
The server is delivering only part of the resource due to a range header sent by the client. Used for resumable downloads.
The URL of the requested resource has been changed permanently. The new URL is given in the Location header. Browsers will redirect automatically.
The URI of requested resource has been changed temporarily. Future requests should still use the original URI. Browsers redirect with the original method.
The resource has not been modified since the version specified by the request headers (If-Modified-Since / If-None-Match). Used for caching.
The server sends this to direct the client to another URI using the same HTTP method as the original request. Unlike 302, the method must not change.
The resource is now permanently at another URI, specified by the Location header. Like 301, but the HTTP method must not change.
The server cannot process the request due to something perceived to be a client error (malformed syntax, invalid request message framing, or deceptive request routing).
The client must authenticate itself to get the requested response. The WWW-Authenticate header contains how to authenticate. Despite the name, it means "unauthenticated."
The client does not have access rights to the content. Unlike 401, the server knows the client's identity but refuses to authorize the request.
The server cannot find the requested resource. This can also mean the resource exists but the server does not want to reveal that information.
The request method is known by the server but is not supported by the target resource. The Allow header must list the supported methods.
The server would like to shut down this unused connection. Sent when the server wants to time out a connection that is taking too long.
The request conflicts with the current state of the target resource. Common with PUT when trying to update a resource that has been modified by another request.
The target resource is no longer available and this condition is likely permanent. Unlike 404, this is a permanent condition and search engines will remove the URL from their index.
The request entity is larger than the server is willing or able to process. The server may close the connection or return a Retry-After header.
The media format of the requested data is not supported by the server. Check the Content-Type header of your request.
The request was well-formed but was unable to be followed due to semantic errors. Common in REST APIs for validation failures.
The user has sent too many requests in a given amount of time (rate limiting). The Retry-After header may indicate when to try again.
The user requested a resource that is not available for legal reasons, such as a censored page or a government-blocked resource.
The server has encountered a situation it does not know how to handle. A generic server-side error when no more specific message is suitable.
The request method is not supported by the server and cannot be handled. Only GET and HEAD are required to be supported by all servers.
The server, while working as a gateway or proxy, received an invalid response from the upstream server. Check upstream service health.
The server is not ready to handle the request. Common causes: maintenance or overload. The Retry-After header may indicate when to retry.
The server, while working as a gateway or proxy, did not receive a timely response from the upstream server needed to complete the request.
Select a status code to see details
4
Informational
5
Success
Redirection
13
Client Error
Server Error