HTTP Status Code Reference

The server has received the request headers and the client should proceed to send the body.

In practice: Rarely seen directly — used internally in request negotiation (e.g. with `Expect: 100-continue`).

The server is switching protocols as requested by the client (e.g. to WebSocket).

In practice: Normal during a WebSocket handshake upgrade.

The request succeeded.

In practice: The standard successful response for GET/POST/etc.

The request succeeded and a new resource was created as a result.

In practice: Typical response to a successful POST that creates a record.

The request has been accepted for processing, but processing is not complete.

In practice: Common for asynchronous/queued jobs.

The request succeeded, but there is no content to return in the response body.

In practice: Common for successful DELETE requests or actions with nothing to show back.

The server is delivering only part of the resource, as requested via a Range header.

In practice: Used for resumable downloads and video/audio seeking.

The request has more than one possible response; the client should choose one.

In practice: Rarely used in practice.

The resource has been permanently moved to a new URL.

In practice: Search engines transfer ranking signals to the new URL — the standard choice for a permanent redirect.

The resource temporarily resides at a different URL.

In practice: Historically used loosely for both temporary and permanent redirects; 303/307/308 exist to remove that ambiguity.

The response to the request can be found at another URL using a GET request.

In practice: Common after a POST, to redirect to a result page without allowing a form resubmission on refresh.

The resource has not changed since the version specified by the request's cache headers.

In practice: Lets the client reuse its cached copy — saves bandwidth, not an error.

The resource temporarily resides at a different URL; the request method must not change.

In practice: Unlike 302, guarantees the original HTTP method (e.g. POST stays POST) is preserved on the redirect.

The resource has permanently moved to a different URL; the request method must not change.

In practice: The method-preserving equivalent of 301.

The server cannot process the request due to a client error (malformed syntax, invalid data, etc.).

In practice: A generic catch-all for "the request itself was wrong."

Authentication is required and has failed or has not been provided.

In practice: Despite the name, this means "not authenticated," not "not authorized" — see 403 for that.

The server understood the request but refuses to authorize it.

In practice: The client's identity is known; it just isn't allowed to do this.

The server cannot find the requested resource.

In practice: Also commonly returned deliberately to avoid confirming a resource's existence.

The request method is known but not supported by this resource.

In practice: E.g. sending POST to an endpoint that only accepts GET.

The server timed out waiting for the request.

In practice: The client took too long to send the full request.

The request conflicts with the current state of the target resource.

In practice: Common for edit conflicts or duplicate-creation attempts.

The resource is no longer available and this condition is expected to be permanent.

In practice: Stronger signal than 404 — tells crawlers the removal was intentional and permanent.

The request body is larger than the server is willing or able to process.

In practice: Common when a file upload exceeds a server's configured size limit.

The requested URI is longer than the server is willing to interpret.

In practice: Often caused by an overly long query string.

The request body's media type is not supported by the server.

In practice: E.g. sending XML to an endpoint that only accepts JSON.

Defined in the 1998 April Fools' RFC 2324 as a joke; never a real production status code.

In practice: Occasionally used deliberately by developers as an easter egg — not something to design around.

The request was well-formed but contains semantic errors (e.g. failed validation).

In practice: Common for API validation failures where the JSON/body syntax itself was fine.

The client has sent too many requests in a given time period (rate limiting).

In practice: Often paired with a Retry-After header telling the client when to try again.

The server encountered an unexpected condition that prevented it from fulfilling the request.

In practice: A generic "something broke on the server" — the fault is server-side, not the client's request.

The server does not support the functionality required to fulfill the request.

In practice: The request method/feature simply isn't implemented by this server.

The server, acting as a gateway or proxy, received an invalid response from an upstream server.

In practice: Usually means a proxy/load balancer's backend server failed or returned garbage.

The server is currently unable to handle the request, typically due to overload or maintenance.

In practice: Often temporary — frequently paired with a Retry-After header.

The server, acting as a gateway or proxy, did not receive a timely response from an upstream server.

In practice: Usually means the backend took too long to respond, not that it errored outright.