HTTP Status Codes Reference

The server agrees to switch protocols as requested by the client. — Used when upgrading to WebSocket or HTTP/2.

The server has received and is processing the request, but no response is available yet. — Used by WebDAV to prevent request timeout.

Used to return response headers before the final HTTP message. — Enables preloading of resources while the server prepares a response.

The request succeeded and a new resource was created. — Should include a Location header pointing to the new resource.

The request has been accepted for processing, but processing is not complete. — Used for async operations. Response may include a way to track processing.

The request succeeded but the response is from a transforming proxy. — The enclosed content is from a third party source, not the origin server.

The request succeeded but there is no content to return. — Common response for DELETE and PUT when no body should be returned.

Tells the client to reset the document view that sent this request. — Used for clearing a form after submission.

The server is delivering only part of the resource due to a range header. — Used for resumable downloads and streaming media.

Conveys information about multiple resources in a single response. — WebDAV extension. Body contains XML with individual status for each resource.

The members of a DAV binding have already been enumerated. — WebDAV extension to prevent duplicate enumeration in a 207 response.

The server has fulfilled a GET request, and the response represents the result of one or more instance manipulations. — Used for HTTP delta encoding.

The resource has been permanently moved to a new URL. — Browsers cache this redirect. Update your links. Use 308 to preserve the HTTP method.

The resource is temporarily at a different URI. — Browsers often change POST to GET on redirect. Use 307 to preserve method.

The server redirects the client to a different resource with GET. — Used after POST to redirect to a confirmation page (PRG pattern).

The resource has not changed since the version specified by the request headers. — Client uses If-None-Match or If-Modified-Since. No body is returned — use cached copy.

The resource is temporarily at a different URI. Method and body must not change. — Like 302 but guarantees the same HTTP method is used after redirect.

The resource has been permanently moved. Method and body must not change. — Like 301 but guarantees the same HTTP method is used after redirect.

The client must authenticate itself to get the requested response. — Despite the name, this means unauthenticated. Use 403 for authenticated but forbidden.

Reserved for future use. Originally intended for digital payment systems. — Some APIs use this for rate limiting or paywall scenarios.

The client is authenticated but does not have access rights to the content. — Unlike 401, the client's identity is known. Revealing the resource exists is intentional.

The server cannot find the requested resource. — Can also be used instead of 403 to hide resource existence from unauthorized users.

The request method is known but not supported for the target resource. — Response must include an Allow header listing supported methods.

The server cannot produce a response matching the Accept headers. — Server-driven content negotiation failed. Client should use different Accept headers.

The client must authenticate with a proxy. — Similar to 401 but for proxy access.

The server timed out waiting for the request. — Server wants to shut down this unused connection. Client may repeat the request.

The request conflicts with the current state of the resource. — Common for edit conflicts, duplicate creation, or state machine violations.

The resource is permanently deleted with no forwarding address. — More specific than 404. Tells clients to remove links to the resource.

The server refuses to accept the request without a defined Content-Length. — Add a Content-Length header to the request.

The server does not meet one of the preconditions set by the client. — Conditional request failed — If-Match or If-Unmodified-Since header mismatch.

The request body is larger than the server is willing or able to process. — Previously called 'Payload Too Large'. Server may close connection or return Retry-After.

The URI requested is longer than the server is willing to interpret. — Usually caused by converting a POST to GET with long query parameters.

The media format of the request data is not supported by the server. — Check Content-Type and Content-Encoding headers.

The range specified in the Range header cannot be fulfilled. — The range is outside the size of the resource.

The expectation given in the Expect request header could not be met. — The server cannot meet the requirements of the Expect: 100-continue header.

The server refuses to brew coffee because it is a teapot. — An April Fools' joke from RFC 2324 (1998). Some APIs use it for easter eggs.

The request was directed at a server that is not able to produce a response. — Server is not configured to handle the combination of scheme and authority in the request.

The request was well-formed but the server is unable to process the contained instructions. — Semantic errors — the body is valid JSON/XML but fails validation rules.

The resource that is being accessed is locked. — WebDAV extension.

The request failed because it depended on another request that failed. — WebDAV extension.

The server is unwilling to risk processing a request that might be replayed. — Prevents replay attacks in early data (0-RTT) TLS connections.

The client should switch to a different protocol. — The server refuses to perform the request using the current protocol.

The origin server requires the request to be conditional. — Prevents the 'lost update' problem — clients must use If-Match for updates.

The user has sent too many requests in a given amount of time. — Include Retry-After header to tell the client when to try again.

The server is unwilling to process the request because its header fields are too large. — Reduce the size of request headers (e.g. large cookies).

The server is denying access due to a legal demand to do so. — Named after Fahrenheit 451. Include Link header pointing to the demand.

The server does not support the functionality required to fulfill the request. — The request method is not recognized or the server lacks the capability.

The server received an invalid response from an upstream server. — Common when a reverse proxy (nginx/load balancer) cannot reach the backend.

The server is temporarily unable to handle the request. — Include Retry-After header. Used for maintenance, overload, or cold starts.

The gateway or proxy did not receive a timely response from an upstream server. — The backend took too long to respond. Check for slow queries or network issues.

The server does not support the HTTP protocol version used in the request. — Rare in modern deployments.

Transparent content negotiation for the request results in a circular reference. — Server configuration error in content negotiation.

The server is unable to store the representation needed to complete the request. — WebDAV extension.

The server detected an infinite loop while processing the request. — WebDAV extension.

Further extensions to the request are required for the server to fulfill it. — The server requires the request to use an extension not supported.

The client needs to authenticate to gain network access. — Used by captive portals (hotel WiFi, etc.).