HTTP Status Code Reference
Look up all HTTP status codes (1xx–5xx) with descriptions and RFC references. Searchable and filterable.
The server has received the request headers. 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 the final HTTP message is ready.
The request has succeeded. The meaning depends on the HTTP method used.
The request has been fulfilled and resulted in a new resource being created.
The request has been accepted for processing but the processing has not been completed.
The returned metadata in the response headers is not the same as available from the origin server.
The server successfully processed the request and is not returning any content.
The server successfully processed the request, but is not returning any content. The client should reset the document view.
The server is delivering only part of the resource due to a range header sent by the client.
The message body contains an XML message with separate response codes for multiple sub-requests.
The members of a DAV binding have already been enumerated in a preceding part of the multi-status response.
The server has fulfilled a GET request and the response is a representation of one or more instance-manipulations applied to the resource.
The target resource has more than one representation; the client should choose one.
The target resource has been permanently moved to a new URI. Future references should use the new URI.
The target resource temporarily resides under a different URI. The client should continue using the original URI.
The server is redirecting the client to a different resource indicated by the Location header.
The resource has not been modified since the version specified by the request headers. No need to retransmit the resource.
The target resource resides temporarily under a different URI. The client MUST NOT change the request method.
The target resource has been permanently moved. The client MUST NOT change the request method for future requests.
The server cannot process the request due to a client error (e.g., malformed syntax, invalid framing, or deceptive request routing).
The request lacks valid authentication credentials. The client must authenticate itself to get the requested response.
Reserved for future use. Originally intended for digital payment systems; rarely used in practice.
The server understands the request but refuses to authorize it. Re-authenticating will not help.
The origin server could not find a current representation for the target resource.
The method in the request-line is known by the server but not supported by the target resource.
The server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers.
The client must first authenticate itself with the proxy.
The server did not receive a complete request message within its expected time.
The request could not be completed due to a conflict with the current state of the target resource.
The target resource is no longer available at the origin server and this condition is likely permanent.
The server refuses to accept the request without a defined Content-Length.
One or more conditions in the request header fields evaluated to false when tested on the server.
The server is refusing to process a request because the request content is larger than the server is willing to process.
The server refuses to service the request because the request-target is longer than the server is willing to interpret.
The server refuses to accept the request because the payload format is in an unsupported format.
None of the ranges in the request's Range header field overlap the current extent of the selected resource.
The expectation given in the request's Expect header field could not be met by at least one of the inbound servers.
Any attempt to brew coffee with a teapot should result in this error code. (April Fools' joke, RFC 2324)
The request was directed at a server that is unable to produce a response.
The server understands the content type but was unable to process the instructions contained in the request content.
The source or destination resource of a method is locked.
The method could not be performed because the requested action depended on another action that failed.
The server is unwilling to risk processing a request that might be replayed.
The server refuses to perform the request using the current protocol but might do so after an upgrade.
The origin server requires the request to be conditional to prevent the 'lost update' problem.
The user has sent too many requests in a given amount of time (rate limiting).
The server is unwilling to process the request because its header fields are too large.
The server is denying access to the resource as a consequence of a legal demand.
The server encountered an unexpected condition that prevented it from fulfilling the request.
The server does not support the functionality required to fulfill the request.
The server, acting as a gateway or proxy, received an invalid response from an upstream server.
The server is not ready to handle the request, often due to maintenance or overloading.
The server, acting as a gateway or proxy, did not receive a timely response from an upstream server.
The server does not support the major version of HTTP used in the request.
The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation.
The server is unable to store the representation needed to successfully complete the request.
The server terminated an operation because it encountered an infinite loop while processing the request.
Further extensions to the request are required for the server to fulfill it.
The client needs to authenticate to gain network access (e.g., captive portal).
61 of 61 status codes
About this tool
HTTP status codes are three-digit integers included in every HTTP response to indicate the outcome of the request. They are defined by IANA and documented across multiple RFCs (primarily RFC 9110). The first digit indicates the response class: 1xx for informational responses (the request was received and is being processed), 2xx for success, 3xx for redirection, 4xx for client errors (the request is invalid), and 5xx for server errors (the server failed to process a valid request).
The most consequential codes to understand: 200 OK (success), 201 Created (resource created, typically returned after POST), 204 No Content (success with no response body, common for DELETE), 301 Moved Permanently (permanent redirect, search engines update their index), 302 Found (temporary redirect, search engines do not update index), 304 Not Modified (client's cached version is current), 400 Bad Request (malformed request syntax or invalid parameters), 401 Unauthorized (authentication is required or failed), 403 Forbidden (authenticated but not authorized), 404 Not Found, 422 Unprocessable Entity (valid syntax but semantic validation failed), 429 Too Many Requests (rate limited), 500 Internal Server Error, 502 Bad Gateway (upstream server error), 503 Service Unavailable (server temporarily overloaded or in maintenance).
HTTP status codes have practical implications beyond error messages. 301 vs 302 affects SEO link equity transfer. 401 vs 403 tells the client whether to prompt for credentials or show an access denied message. 429 should be accompanied by a Retry-After header so clients know when to retry. 503 should also include Retry-After. Using the semantically correct code makes APIs self-documenting and allows generic HTTP infrastructure (caches, proxies, monitoring systems, clients) to handle responses appropriately.