HTTP Status Code Lookup

Server has received the request headers and the client should proceed to send the request body. Used in conjunction with the Expect: 100-continue request header to avoid sending a large body if the server would reject it based on the headers alone.

Server is switching protocols as requested by the Upgrade request header. Most commonly seen with WebSocket upgrades from HTTP.

WebDAV: server has accepted the request but processing will take time. Mostly deprecated — keep-alive is the modern equivalent.

Server is sending hint headers (typically Link: rel=preload) before the final response. Lets browsers start preloading critical resources before the server finishes processing.

Request succeeded. The body of the response carries the result. The most common success status — used for GETs that return data, PUTs that update existing resources, and most application-level success cases.

Request succeeded and a new resource was created. Response should include a Location header with the URL of the new resource. Standard reply for a POST that creates something.

Request accepted for processing but not yet completed. The processing may end up succeeding or failing — the client must check back. Used for async/queued workflows.

Response was modified by an intermediary (a proxy or CDN) from what the origin server sent. Rare in modern HTTP — most caches forward the original response and just add caching headers.

Request succeeded but there is no response body. Common for DELETEs, PUTs that update without returning the resource, and OPTIONS preflight responses where the server has nothing to return.

Request succeeded; client should reset the document view (clear the form, etc.). Rare in practice.

Server is returning part of a resource because the request used a Range header. Used for resumable downloads, video seeking, and large-file uploads/downloads.

WebDAV: response body contains multiple status codes for multiple sub-operations. Typically with XML body listing per-resource results.

WebDAV: members of a binding have already been reported in a preceding response, so they are not enumerated again.

Server has fulfilled the GET request and the response is the result of one or more instance-manipulations applied to the current instance. Very rare in practice.

Multiple representations of the resource are available; the client must choose which one to use. The Location header may suggest a default. Rare in practice — most APIs don't do content negotiation this way.

Resource has permanently moved to the URL given in the Location header. Search engines update their index to use the new URL. Use for permanent URL changes; do NOT use for temporary moves.

Resource is temporarily at a different URL given in Location. Original URL should still be used for future requests. Most browsers historically converted POST to GET on 302 — use 307/308 if you need explicit semantics.

Result of the request can be retrieved by GETing a different URL. Standard pattern after a POST: respond with 303 + Location to the resource page, so the browser does GET and the user can refresh safely.

Resource has not changed since the validators sent in the request (If-None-Match / If-Modified-Since). Client should use its cached copy. Body is empty.

Deprecated. Originally meant to direct the client through a specific proxy. Modern HTTP doesn't use this status code.

Resource is temporarily at a different URL. Unlike 302, the request method MUST NOT be changed (POST stays POST when retried at the new URL). Use this when method preservation matters.

Resource has permanently moved AND the method must be preserved on retry. Like 301 but with strict method semantics. Use for permanent moves where the method matters (POST APIs, etc.).

Server cannot process the request because of malformed syntax — invalid JSON, missing required field, malformed URL parameter. Client should not retry without modification.

Request requires authentication and either none was provided or the credentials provided are invalid. Server should include a WWW-Authenticate header indicating the required scheme. Despite the name, "unauthorized" really means "unauthenticated".

Reserved for future use. A handful of APIs (Stripe in some flows) use it for billing-related rejections, but no formal definition exists.

Server understood the request and the client is authenticated, but the client doesn't have permission. Use this when the user is logged in but lacks the role needed for the action. Different from 401 (which means "auth needed").

Resource at this URL does not exist (or the server doesn't want to reveal it does). Used both for genuinely missing resources and as a privacy-preserving alternative to 403 when the server doesn't want to confirm existence.

Resource exists but doesn't support the request method. Server MUST include an Allow header listing supported methods. Common when POSTing to a read-only endpoint.

Server cannot produce a response matching the Accept headers sent in the request. Most modern APIs ignore Accept negotiation entirely and respond with what they have.

Like 401 but the proxy itself requires authentication. Client must authenticate with the proxy first.

Server timed out waiting for the client to finish sending the request. Client may retry. Some servers use this to close idle keep-alive connections.

Request conflicts with the current state of the resource. Common for: PUT with stale ETag, POST creating something that already exists, mutating a resource being concurrently modified.

Resource at this URL existed but has been permanently removed and won't be back. Stronger than 404 — tells search engines to drop the URL from their index.

Server requires a Content-Length header but the request didn't include one. Client should add the header and retry.

Conditional request failed (If-Match, If-Unmodified-Since, etc. didn't match server state). Client should refresh and retry with current values.

Request body exceeds server's configured maximum size. Sometimes used for upload size limits. Was called "Payload Too Large" pre-RFC 9110.

Request URL is longer than the server is willing to interpret. Common cause: very long query strings. Switch to POST with a body if you need to send a lot of data.

Request body is in a format the server does not support (the Content-Type header). Common when an API expects JSON and receives form-encoded data, or vice versa.

Range header specified a range that doesn't exist in the resource (e.g. requesting bytes 100-200 of a 50-byte file).

Server cannot meet the expectation in the Expect request header. Rarely seen in practice.

April Fools' joke from the Hyper Text Coffee Pot Control Protocol (HTCPCP). Some sites return it for blocked or troll-detection responses, but it has no formal HTTP semantics.

Request was directed to a server that cannot produce a response for the requested authority (host). Common with HTTP/2 connection coalescing when a request reaches a backend that doesn't serve the requested host.

Request was syntactically valid but semantically wrong — e.g. JSON body parsed but the values failed business validation. Common alternative to 400 in REST APIs that want to distinguish "malformed" from "invalid". Was "Unprocessable Entity" pre-RFC 9110.

WebDAV: resource is locked. The lock owner may be different from the requester.

WebDAV: request failed because a previous request in the same context failed.

Server is unwilling to process a request that might be replayed (used with TLS 1.3 0-RTT data). Client should retry over a fully-established TLS connection.

Server refuses to process the request without an upgraded protocol (e.g. requires HTTPS).

Server requires the request to be conditional (e.g. include an If-Match header). Used by APIs to enforce optimistic concurrency control on writes.

Client has sent too many requests in a given time window — rate-limited. Server SHOULD include a Retry-After header indicating when to retry.

Server is unwilling to process the request because the headers (collectively or one of them) are too large.

Server is denying access for legal reasons (court order, GDPR, geo-blocking, copyright takedown). Status code number is a reference to Ray Bradbury's Fahrenheit 451.

Server encountered an unexpected condition. The catch-all "something went wrong on our end". Don't use 500 for client mistakes — use 4xx codes. 500 should mean genuine server bug.

Server doesn't support the request method. Different from 405 (which means "this resource doesn't support the method") — 501 means "this server doesn't support the method at all".

Server (acting as proxy/gateway) received an invalid response from an upstream. Typical cause: backend service is down or returning malformed responses. Common with reverse-proxy setups.

Server is temporarily overloaded or down for maintenance. Includes a Retry-After header when possible. Clients SHOULD retry; load balancers may stop sending traffic when seeing 503.

Server (proxy/gateway) timed out waiting for an upstream response. The upstream service might be slow or unresponsive. Different from 502 (got bad response) and 503 (server itself down).

Server doesn't support the HTTP protocol version used in the request. Rare — most servers are lenient about minor version differences.

Server has an internal configuration error: the chosen variant is itself configured to perform content negotiation (loop).

WebDAV: server is unable to store the representation needed to complete the request. Typically: out of disk space.

WebDAV: server detected an infinite loop while processing the request.

Further extensions to the request are required for the server to fulfill it. Effectively unused.

Client needs to authenticate to gain network access (typically a captive portal at a wifi hotspot).

Non-standard. Used by some HTTP libraries and CDNs to indicate the connection to the upstream timed out before the response started. Not part of any RFC.