Searchable, color-coded reference of HTTP status codes across 1xx-5xx with plain-English explanations.
The server has received the request headers and the client should proceed to send the request body.
The server is switching protocols as requested by the client, e.g. upgrading to WebSocket.
The server has received and is processing the request, but no response is available yet (WebDAV).
Used to return preload/preconnect hints before the final HTTP response is ready.
The request succeeded. The meaning depends on the HTTP method (GET returns a resource, POST returns a result).
The request succeeded and a new resource was created as a result, typically after a POST or PUT.
The request has been accepted for processing, but processing hasn't completed yet.
The returned metadata is not exactly the same as from the origin server, e.g. served via a proxy.
The request succeeded but there is no content to return, often used after a DELETE or PUT.
The request succeeded; tells the client to reset the document view that sent this request.
Used with range requests to deliver only part of a resource, e.g. resumable downloads or video streaming.
Conveys information about multiple resources in situations where multiple status codes may be appropriate (WebDAV).
The server has fulfilled a GET request and the response is a representation of the result of instance manipulations.
The request has more than one possible response; the user or agent should choose one of them.
The resource has been permanently moved to a new URL; future requests should use the new URL.
The resource temporarily resides at a different URL; the client should keep using the original URL for future requests.
The response can be found at another URL using a GET request, commonly used after a form submission (POST/redirect/GET).
The resource hasn't changed since the last request; the client can use its cached version.
The requested resource must be accessed through the proxy given in the response. Deprecated for security reasons.
Like 302, but guarantees the method and body of the original request are repeated on the redirected request.
Like 301, but guarantees the method and body of the original request are repeated on the redirected request.
The server cannot process the request due to a client error, such as malformed syntax.
Authentication is required and has failed or has not yet been provided.
Reserved for future use; originally intended for digital payment systems.
The server understood the request but refuses to authorize it, regardless of authentication.
The server can't find the requested resource; the endpoint may not exist or the URL is wrong.
The request method is known by the server but is not supported for this particular resource.
The server can't produce a response matching the list of acceptable values in the request's headers.
Similar to 401, but authentication is needed with a proxy first.
The server timed out waiting for the request from the client.
The request conflicts with the current state of the target resource, e.g. an edit conflict.
The requested resource is permanently gone and no forwarding address is available, unlike 404.
The server refuses the request because the Content-Length header was not specified.
One or more conditions in the request headers evaluated to false, e.g. a failed If-Match check.
The request body is larger than the server is willing or able to process.
The URI requested by the client is longer than the server is willing to interpret.
The media format of the requested data is not supported by the server.
The range specified by the Range header cannot be fulfilled for the resource.
The server can't meet the requirements of the Expect request-header field.
A joke status code from the 1998 April Fools' Hyper Text Coffee Pot Control Protocol; a server refuses to brew coffee.
The request was directed at a server that is not able to produce a response for this combination of scheme and host.
The request was well-formed but contains semantic errors, e.g. failed validation (common in REST APIs).
The resource being accessed is locked (WebDAV).
The request failed because it depended on another request that failed (WebDAV).
The server is unwilling to risk processing a request that might be replayed, sent in early data (TLS 0-RTT).
The server refuses to perform the request using the current protocol; the client should switch to a different protocol.
The origin server requires the request to be conditional, to avoid the lost update problem.
The user has sent too many requests in a given amount of time; used for rate limiting.
The server refuses to process the request because its header fields are too large.
The requested resource is unavailable due to a legal demand, such as government-mandated censorship.
A generic error indicating the server encountered an unexpected condition it doesn't know how to handle.
The request method isn't supported by the server and can't be handled.
The server, acting as a gateway or proxy, received an invalid response from an upstream server.
The server isn't ready to handle the request, often due to maintenance or being overloaded.
The server, acting as a gateway or proxy, didn't get a response in time from an upstream server.
The HTTP version used in the request isn't supported by the server.
The server has an internal configuration error: transparent content negotiation results in a circular reference.
The server is unable to store the representation needed to complete the request (WebDAV).
The server detected an infinite loop while processing the request (WebDAV).
Further extensions to the request are required for the server to fulfill it.
The client needs to authenticate to gain network access, e.g. a captive portal on public Wi-Fi.