HTTP Status Codes — Lookup & Decision Helper

The client should continue sending the request body. Sent in response to an Expect: 100-continue header before the client commits to uploading a large payload.

The server agrees to switch protocols as requested in the Upgrade header — most commonly the HTTP→WebSocket handshake.

WebDAV interim response telling the client the server has accepted a long-running request and is still working on it. Deprecated in favour of more reliable mechanisms.

An interim response that lets the server send Link headers early so the browser can preconnect or preload resources before the final response is ready.

The request succeeded. The meaning of the body depends on the method: the representation of the target resource for GET, the result of the action for POST, and so on.

The request succeeded and one or more new resources were created. The Location header should point at the new resource; the body usually describes it.

The request was accepted for processing, but the processing has not completed and may not succeed. Used for asynchronous / queued work.

The request succeeded but the enclosed body was modified by a transforming proxy from the origin's 200 response. Status of the original is 200.

The request succeeded and there is no additional content to send in the body. Commonly returned by a successful PUT or DELETE.

The request succeeded and the user agent should reset the document that sent the request (e.g. clear a form). A 205 must not include a body.

The server is delivering only part of the resource in response to a Range request. Used for resumable downloads and media streaming.

WebDAV: the body is an XML document carrying multiple independent status codes for a request that affected several resources.

WebDAV: used inside a Multi-Status (207) body to avoid repeatedly enumerating the members of a binding already reported earlier.

The server fulfilled a GET and the response is one or more instance-manipulations (delta encoding) applied to the current instance.

The target has more than one representation and the server cannot pick one for the client. The body may list the alternatives.

The resource has a new permanent URL given in Location. Clients and search engines should update their links. A client MAY change the method to GET on the redirect.

The resource is temporarily at a different URL given in Location. The original URL should keep being used for future requests. A client MAY change the method to GET.

Tells the client to GET a different URL (in Location) to see the result of the request. The classic Post/Redirect/Get pattern that stops form resubmission.

Used for conditional GETs: the cached copy is still fresh, so no body is sent. Triggered by If-None-Match / If-Modified-Since.

Deprecated. Originally meant the resource must be accessed through a proxy. No longer used because of security concerns.

The resource is temporarily at the Location URL, and the client MUST repeat the request with the same method and body. The method-preserving version of 302.

The resource has permanently moved to the Location URL, and the client MUST reuse the same method and body. The method-preserving version of 301.

The server cannot or will not process the request because of a client error — malformed syntax, invalid framing, or deceptive routing.

The request lacks valid authentication. The response must include a WWW-Authenticate header; the client can retry with credentials. ('Unauthenticated' would be the accurate name.)

Reserved for future use. Used by some APIs to signal that payment or a higher plan is required before the request can proceed.

The server understood the request but refuses to authorise it. Unlike 401, authenticating will not help — the identity is known but not permitted.

The origin server did not find a current representation for the target resource, or does not wish to disclose that one exists. Does not say whether the absence is temporary or permanent.

The method is known by the server but not supported by the target resource. The response must list supported methods in an Allow header.

The server cannot produce a response matching the Accept headers sent in the request (content type, language, or encoding).

Like 401, but authentication is needed by a proxy between the client and the server. The proxy sends a Proxy-Authenticate header.

The server timed out waiting for the full request. The client may repeat the request; servers often close idle keep-alive connections this way.

The request conflicts with the current state of the target resource — e.g. an edit against a stale version, or a duplicate that breaks a uniqueness rule.

The resource is permanently gone and no forwarding address is known. Stronger than 404 — tells clients and search engines to stop requesting it.

The server refuses the request because it has no Content-Length header. The client must add one and resend.

A conditional header (If-Match, If-Unmodified-Since, etc.) evaluated to false, so the server did not perform the request. Guards against lost updates.

The request body is larger than the server is willing or able to process. Formerly called 'Payload Too Large'.

The request URI is longer than the server is willing to interpret — often a GET with too many query parameters that should be a POST.

The request body is in a format the target resource does not support (wrong Content-Type or Content-Encoding).

None of the ranges in the request's Range header overlap the current extent of the resource — e.g. a byte range beyond the file size.

The expectation in the request's Expect header could not be met by the server.

An April Fools' joke code (RFC 2324, Hyper Text Coffee Pot Control Protocol). RFC 9110 lists 418 as reserved/unused so it can never be reassigned. Not for real use.

The request was directed at a server that is unable or unwilling to produce an authoritative response for the target URI's authority (common with HTTP/2 connection reuse).

The request was well-formed (correct syntax and content type) but the server could not process the contained instructions — typically semantic validation errors.

WebDAV: the target resource is locked and cannot be modified.

WebDAV: the request failed because it depended on another request that failed.

The server is unwilling to risk processing a request that might be replayed — sent over TLS 1.3 early data (0-RTT).

The server refuses the request on the current protocol but will accept it after the client upgrades. The Upgrade header lists the required protocol(s).

The origin server requires the request to be conditional, to prevent the 'lost update' problem from blind overwrites. The client should add an If-Match.

The client has sent too many requests in a given time (rate limiting). The response should include a Retry-After header telling the client when to try again.

The server refuses the request because its header fields are too large, either individually or in total. Often an oversized Cookie.

The resource is unavailable for legal reasons, such as a court order or government censorship. The number nods to Fahrenheit 451.

A generic catch-all: the server hit an unexpected condition that stopped it fulfilling the request. The most common server-side error.

The server does not support the functionality required to fulfil the request — e.g. an unrecognised method. The only 5xx that is cacheable by default.

The server, acting as a gateway or proxy, got an invalid response from the upstream server it relied on.

The server is temporarily unable to handle the request — overloaded or down for maintenance. A Retry-After header may say when to come back.

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

The server does not support, or refuses to support, the major HTTP version used in the request.

A transparent content-negotiation configuration error: the chosen variant is itself configured to negotiate, causing a loop.

WebDAV: the server cannot store the representation needed to complete the request — out of disk or quota.

WebDAV: the server detected an infinite loop while processing the request (e.g. cyclic bindings).

An extension to the request is required for the server to fulfil it. Defined by the experimental (now obsolete) HTTP Extension Framework; rarely seen.

The client needs to authenticate to gain network access — sent by captive portals (e.g. public Wi-Fi login pages).