HTTP Status Codes

The server received the request headers and the client should proceed to send the request body. Used with the Expect: 100-continue header on large uploads.

The server agrees to switch to the protocol the client requested in the Upgrade header — most commonly seen when establishing a WebSocket connection.

The server accepted the full request but has not completed it yet. A WebDAV interim response used to prevent client timeouts on long operations.

An interim response that lets the server send Link headers (preload/preconnect) before the final response is ready, so browsers can start fetching critical assets earlier.

The request succeeded. The response body contains the result — a page for GET, the operation outcome for POST.

The request succeeded and a new resource was created. The Location header usually points at the new resource — the canonical response for a successful POST in REST APIs.

The request was accepted for processing, but processing hasn't completed — and may still fail. Common for queued/asynchronous jobs.

The request succeeded, but the response was modified by a transforming proxy between the origin and the client.

The request succeeded and there is intentionally no response body. Typical for DELETE operations and for PUT/PATCH when the server returns nothing.

Like 204, but additionally tells the client to reset the document view — e.g. clear the form that produced the request.

The server is delivering only the byte range requested via the Range header. The backbone of video streaming, download resumption and large-file delivery.

A WebDAV response carrying multiple status codes for multiple resources in one XML body — e.g. a PROPFIND across a folder tree.

Used inside a 207 Multi-Status body to avoid repeating members of a binding that were already listed earlier in the same response.

The response is the result of applying instance manipulations (such as a delta encoding) to the current resource. Rare in practice.

More than one representation of the resource exists and the client should pick one. Rarely used — most servers pick a representation themselves.

The resource has permanently moved to the URL in the Location header. Browsers cache it and search engines transfer ranking signals to the new URL.

The resource temporarily lives at another URL. Search engines keep the original URL indexed; browsers don't cache the redirect.

Tells the client to fetch a different URL with GET — the standard way to redirect after a POST (Post/Redirect/Get pattern).

The cached copy the client holds is still valid — the server sends no body. The result of conditional requests with If-None-Match (ETag) or If-Modified-Since.

Like 302, but the client must repeat the request to the new URL with the same method and body — a POST stays a POST.

Permanent counterpart of 307: the resource moved for good and the method/body must be preserved when following the redirect.

The server can't or won't process the request because the client sent something malformed — invalid JSON, bad query parameters, broken headers or framing.

Authentication is required and was missing or invalid. Despite the name, it means "unauthenticated" — the response includes a WWW-Authenticate challenge.

Reserved originally for digital payments; today used by some APIs to signal exceeded quotas, expired subscriptions, or billing problems.

The server understood the request and refuses to authorize it. Unlike 401, re-authenticating won't help — the identity is known but lacks permission.

The server can't find anything at the requested URL. It says nothing about whether the resource ever existed or will exist.

The URL exists but doesn't support the HTTP method used — e.g. POSTing to a GET-only endpoint. The Allow header lists what's permitted.

The server can't produce a response matching the client's Accept headers (content type, language, encoding).

Like 401, but the authentication challenge comes from a proxy between you and the target (Proxy-Authenticate header).

The server gave up waiting for the client to finish sending the request. Servers often close the connection afterwards.

The request conflicts with the resource's current state — classic cases are duplicate creation and stale optimistic-locking versions.

The resource existed but was intentionally and permanently removed. Stronger than 404 — clients and crawlers should stop asking.

The server insists on a Content-Length header and the request didn't include one (e.g. chunked uploads it refuses to accept).

A conditional header (If-Match, If-Unmodified-Since…) evaluated to false — the resource changed since the client last saw it.

The request body exceeds what the server is willing to process. Formerly called 'Payload Too Large'.

The request URL exceeds the server's limit — usually a symptom of stuffing data into the query string.

The server refuses the request because the body's media type (Content-Type/Content-Encoding) isn't supported by the endpoint.

The Range header asks for bytes outside the resource's actual size — e.g. resuming a download past the end of the file.

The server can't meet the requirements of the Expect header (almost always Expect: 100-continue).

An April Fools' joke from the Hyper Text Coffee Pot Control Protocol: the server is a teapot and refuses to brew coffee. Some real services use it as a playful block response.

The request reached a server that isn't configured to answer for that scheme/authority — common with HTTP/2 connection reuse across hostnames.

The request is syntactically valid but semantically wrong — well-formed JSON that fails business validation (missing fields, invalid values).

The WebDAV resource is locked by another client and the request would violate the lock.

The request failed because an earlier request it depended on (in the same WebDAV operation) failed.

The server refuses to process a request sent in TLS early data (0-RTT) because it might be replayed.

The server refuses to serve the request over the current protocol; the Upgrade header says which protocol to switch to.

The server requires the request to be conditional — send If-Match/If-Unmodified-Since to avoid lost-update races.

The client exceeded the rate limit. The Retry-After header (when present) says how long to back off.

Headers (one or all together) are too large for the server — very often a bloated Cookie header.

Access is denied for legal reasons — court orders, government censorship, or geo-specific legal restrictions (the number nods to Fahrenheit 451).

A generic 'something broke on the server' — an unhandled exception or misconfiguration with no more specific status to report.

The server doesn't support the functionality required — typically an HTTP method it doesn't implement at all (contrast 405: method known, not allowed here).

A gateway/reverse proxy got an invalid response from the upstream server — the proxy is fine, the thing behind it isn't answering properly.

The server is temporarily unable to handle the request — overloaded, in maintenance, or deliberately shedding load. Retry-After may say when to come back.

A gateway/proxy didn't get a response from the upstream in time. The upstream may still be processing — the proxy just gave up waiting.

The server doesn't support the HTTP protocol version used in the request.

A server misconfiguration in transparent content negotiation: the chosen variant is itself configured to negotiate, creating a loop.

The server can't store what the request requires — disk or quota exhausted (WebDAV origin, seen in storage-backed APIs).

The server aborted an operation because it found itself in an infinite loop while processing (WebDAV bindings referencing each other).

The request must be extended (HTTP Extension Framework) for the server to fulfill it. Essentially unused on the modern web.

The network (not the website) requires authentication first — the response captive portals send before you log in to hotel/airport Wi-Fi.