HTTP Status Code & Header Reference

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

• Sent automatically by the server in response to a request with an 'Expect: 100-continue' header, before the client uploads a large body.

The server is complying with a client request to switch protocols, most commonly to WebSocket.

• A WebSocket handshake ('Upgrade: websocket') succeeded.

WebDAV: the server has accepted the request but has not yet completed it, sent to prevent client timeout.

• Long-running WebDAV operations like COPY or MOVE on large collections.

Sent before the final response to let the client start preloading resources referenced by Link headers.

• A server/CDN sending preconnect or preload hints while it prepares the actual response.

The request succeeded. The meaning of success depends on the HTTP method (e.g. the resource was fetched for GET).

• A normal, successful request/response cycle.

The request succeeded and a new resource was created as a result, typically after a POST or PUT.

• Successfully creating a new record via an API — usually paired with a Location header pointing to the new resource.

The request has been accepted for processing, but processing hasn't completed — commonly used for async/queued work.

• Submitting a job to a background queue or webhook that will be processed later.

The returned metadata is not exactly the same as from the origin server, typically because a proxy modified it.

• A transforming proxy or CDN altering response headers before passing them on.

The request succeeded but there is no content to send — the existing page should not be refreshed.

• Successful DELETE requests; successful PUT/POST where there's nothing to return; CORS preflight OPTIONS responses.

Tells the client to reset the document that sent the request, e.g. clear a form.

• Rare in practice; used to signal a UI reset after a successful submission.

Delivering only part of a resource due to a Range header sent by the client.

• Video/audio streaming, resumable downloads, and byte-range requests.

WebDAV: conveys information about multiple sub-requests/resources in one response body.

• A WebDAV PROPFIND or batch operation covering several resources with different outcomes.

WebDAV: used inside a DAV binding to avoid re-enumerating the same internal members multiple times.

• WebDAV collections with multiple bindings to the same resource.

The server fulfilled the request and the response is a representation of the result of applying one or more instance manipulations.

• Delta encoding responses (rarely used in practice).

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

• Content negotiation where several representations of a resource are available.

The resource has permanently moved to a new URL; future requests should use the new URL.

• Domain migrations, URL restructuring, enforcing HTTPS or a canonical hostname.

The resource temporarily resides at a different URL. Historically often misused where 303/307 would be more correct.

• Temporary redirects, login flows, load balancing between mirrors.

Directs the client to fetch the response from a different URL using a GET request — the standard post-POST redirect.

• The classic 'redirect after form submission' (POST/redirect/GET) pattern.

The cached version of the resource is still valid; no body is sent. Used with conditional requests.

• A client sending If-None-Match or If-Modified-Since and the resource hasn't changed.

Deprecated: the requested resource must be accessed through the given proxy. Removed from modern browsers for security reasons.

• Legacy proxy-routing configurations; essentially unused today.

Like 302, but guarantees the method and body will NOT change on the redirected request.

• Temporary redirects where preserving the original HTTP method (e.g. POST) matters.

Like 301, but guarantees the method and body will NOT change on the redirected request.

• Permanent redirects where preserving the original HTTP method matters, e.g. API endpoint renames.

The server cannot process the request due to a client error — malformed syntax, invalid request framing, or bad input.

• Invalid JSON body, missing required fields, malformed query parameters.

Authentication is required and has failed or has not been provided. (Despite the name, this is about authentication, not authorization.)

• Missing, expired, or invalid credentials/token/API key.

Reserved for future use; occasionally repurposed by APIs to signal billing/quota issues.

• Some payment/metering APIs use this non-standardly for 'quota exceeded, please pay'.

The server understood the request but refuses to authorize it — the client's identity is known but lacks permission.

• Insufficient permissions/roles, IP allowlist blocks, WAF rule matches, disabled accounts.

The server can't find the requested resource; the URL doesn't correspond to any known route.

• Typo'd URLs, deleted resources, incorrect routing configuration, deployed-but-not-yet-live endpoints.

The HTTP method used isn't supported for this resource (e.g. sending POST to a GET-only endpoint).

• Calling an endpoint with the wrong verb; missing a handler for that method.

The server can't produce a response matching the Accept headers sent by the client.

• Requesting a content type or language the server doesn't support producing.

Like 401, but authentication must happen against a proxy in front of the origin server.

• Corporate/forward proxies requiring credentials before forwarding the request.

The server timed out waiting for the request from the client.

• Slow or idle client connections; keep-alive connections held open too long.

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

• Optimistic-concurrency version mismatches, duplicate unique-key inserts, edit conflicts.

The resource is no longer available and this condition is expected to be permanent, unlike a plain 404.

• Deliberately decommissioned endpoints or content that was intentionally removed.

The server requires a Content-Length header, which the request didn't include.

• Chunked or streamed request bodies sent where the server insists on a known length.

A precondition in the request headers (like If-Match) evaluated to false.

• Conditional requests used for optimistic concurrency where the resource changed since it was fetched.

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

• File uploads exceeding a server, proxy, or CDN body-size limit.

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

• Extremely long query strings, often from putting large data or many parameters in a GET URL.

The request body's media type (Content-Type) isn't supported by the server for this endpoint.

• Sending XML to a JSON-only API, or omitting/mis-setting the Content-Type header.

The Range header sent by the client can't be fulfilled, e.g. the range is outside the resource's size.

• Resuming a download with a stale/incorrect byte-range value.

The server can't meet the requirements of the client's Expect request-header field.

• An 'Expect: 100-continue' header the server or an intermediate proxy doesn't support.

An April Fools' joke from RFC 2324 (Hyper Text Coffee Pot Control Protocol); not expected to be implemented by real servers.

• Easter eggs, or occasionally used by services deliberately blocking bots/scrapers as a joke.

The request was directed at a server that can't produce a response for the combination of scheme/authority in the URI.

• HTTP/2 connection reuse across domains hitting a server not configured for that domain.

The request was well-formed but semantically invalid — e.g. it fails validation rules. Common in REST APIs.

• Failed field-level validation: wrong data types, out-of-range values, business-rule violations.

WebDAV: the resource being accessed is locked.

• A WebDAV client holding a lock on a file that another client tries to modify.

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

• A batched WebDAV operation where an earlier step in the same request failed.

The server is unwilling to process a request that might be replayed, sent in early (0-RTT) TLS data.

• TLS 1.3 0-RTT requests the server considers risky to process before the handshake fully completes.

The server refuses to perform the request using the current protocol and wants the client to upgrade (e.g. to TLS or a newer HTTP version).

• A server requiring HTTPS or HTTP/2 rejecting a plaintext/older-protocol request.

The server requires the request to be conditional (e.g. include If-Match) to avoid the 'lost update' problem.

• APIs enforcing optimistic concurrency by requiring a precondition header on updates.

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

• Hitting an API rate limit; look for a Retry-After header indicating when to try again.

The server is unwilling to process the request because its header fields are too large.

• Oversized cookies, excessively long auth tokens, or too many headers.

The resource is unavailable due to a legal demand, such as a government-mandated content block.

• Court orders, DMCA takedowns, or region-specific legal content restrictions.

A generic error indicating the server encountered an unexpected condition that prevented it from fulfilling the request.

• Unhandled exceptions in application code, null reference errors, misconfiguration.

The server doesn't support the functionality required to fulfill the request, often an unrecognized HTTP method.

• Calling a method or feature the server has never implemented.

A server acting as a gateway or proxy received an invalid response from the upstream server.

• The application server crashed or isn't running, or returned a malformed response the proxy couldn't parse.

The server is temporarily unable to handle the request, often due to overload or maintenance.

• Deployments/maintenance windows, the app server being overwhelmed, health checks failing.

A server acting as a gateway or proxy didn't receive a timely response from the upstream server.

• A slow backend/database query, an origin server hanging, or a proxy timeout set too aggressively.

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

• A client using an unusual or very old/new HTTP version the server can't negotiate.

The server has an internal configuration error: the chosen variant resource is itself configured to engage in content negotiation.

• Misconfigured transparent content negotiation (very rare in practice).

WebDAV: the server is unable to store the representation needed to complete the request.

• The server's disk or storage backend is full.

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

• Circular references in WebDAV bindings.

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

• Rare; tied to the obsolete HTTP Extension Framework.

The client needs to authenticate to gain network access, e.g. a captive portal.

• Public Wi-Fi captive portals intercepting requests before granting internet access.