HTTP status codes: the full list, explained.

The first part of the request was received and the client should send the rest of the body.

In practice: Clients send Expect: 100-continue before a large upload so the server can reject it before the body is transferred.

The server agrees to switch to the protocol the client asked for in the Upgrade header.

In practice: Seen in every WebSocket handshake.

WebDAV interim response: the request is being processed and no final response is ready yet.

In practice: Deprecated: dropped from later WebDAV specifications and rarely seen today.

Interim response with Link headers sent before the final response.

In practice: Lets browsers start preloading CSS, fonts or scripts while the server is still building the page.

The request succeeded. What the body contains depends on the method: the resource for GET, the result of the action for POST.

In practice: The default success response for reads and for actions that return data.

The request succeeded and created one or more new resources.

In practice: Return it from a POST that creates something, with a Location header pointing at the new resource.

The request was accepted for processing, but processing has not finished and may still fail.

In practice: Asynchronous jobs: return 202 with a URL the client can poll for the result.

The request succeeded, but a transforming proxy modified the origin server's 200 response.

In practice: Rare; mostly seen with proxies that rewrite content.

The request succeeded and there is no content to send in the body.

In practice: Common for DELETE and for PUT or PATCH that do not return the updated resource.

The request succeeded and the client should reset the document view that sent it, for example clear a form.

In practice: Rarely used in practice.

The server is returning only the byte ranges the client asked for with a Range header.

In practice: Video and audio streaming, resumable and parallel downloads.

WebDAV: the body carries separate status codes for several operations.

In practice: Batch operations on file servers such as WebDAV or CalDAV.

WebDAV: members of a binding were already listed earlier in the same 207 response.

In practice: Avoids repeating the same resource when a collection is reachable more than once.

The response is the result of instance manipulations applied to the current resource, such as a delta.

In practice: Delta encoding for HTTP; very rare.

The resource has more than one representation and the client may choose between them.

In practice: Rarely used; servers usually pick one representation themselves.

The resource has a new permanent URL, given in the Location header.

In practice: Site migrations and URL changes. Search engines move ranking signals to the new URL. Clients may change POST to GET, so use 308 when the method must be kept.

The resource is temporarily at a different URL.

In practice: Short-lived redirects such as a login bounce. Browsers historically turn POST into GET; use 307 to keep the method.

The client should fetch another URL with GET to see the result.

In practice: The Post/Redirect/Get pattern: after a form POST, redirect to a results page so a refresh does not resubmit.

A conditional GET found the client's cached copy is still current, so no body is sent.

In practice: Caching with ETag / If-None-Match or Last-Modified / If-Modified-Since. Saves bandwidth on repeat visits.

Deprecated. Originally told the client to access the resource through a proxy.

In practice: Do not use; clients ignore it for security reasons.

Reserved. It was used in an earlier draft and is no longer defined.

In practice: Never send it.

The resource is temporarily at another URL and the client must repeat the request with the same method and body.

In practice: Temporary redirects for APIs and form posts where turning POST into GET would be wrong.

The resource has a new permanent URL and the client must keep the same method and body.

In practice: Permanent moves of API endpoints. Like 301 but method-preserving.

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

In practice: Malformed JSON, missing required parameters or invalid query strings.

The request lacks valid authentication credentials. The response must include a WWW-Authenticate header.

In practice: Missing, invalid or expired tokens. Despite the name it means unauthenticated; logging in may fix it.

Reserved for future use.

In practice: Some APIs use it for failed or overdue billing, but there is no standard meaning.

The server understood the request but refuses to fulfil it.

In practice: The client is known but not allowed, such as a missing role or permission. Logging in again will not help.

The server has no current representation for the target resource, or will not reveal that one exists.

In practice: Broken links and unknown IDs. Also used instead of 403 to hide that a private resource exists.

The method is known but not supported by this resource. The response must include an Allow header.

In practice: For example, a DELETE sent to a read-only endpoint.

No representation matches the Accept headers the client sent.

In practice: A client asks for application/xml from an API that only returns JSON.

Like 401, but the client must authenticate with a proxy first (Proxy-Authenticate header).

In practice: Corporate proxies that require login.

The server did not receive a complete request in the time it was prepared to wait.

In practice: Slow or idle clients; the server usually closes the connection.

The request conflicts with the current state of the resource.

In practice: Edit conflicts, duplicate unique values or a version mismatch. Explain how to resolve it in the body.

The resource is no longer available and this is likely permanent.

In practice: Deliberately removed content. Google treats 410 and 404 the same way for indexing.

The server refuses the request without a Content-Length header.

In practice: Uploads without a declared size.

A condition in the request headers, such as If-Match or If-Unmodified-Since, evaluated to false.

In practice: Optimistic concurrency: the resource changed since the client read its ETag.

The request content is larger than the server is willing to process. Formerly Payload Too Large.

In practice: File uploads above the server or proxy size limit.

The request target is longer than the server is willing to interpret.

In practice: Huge query strings; move the data into a POST body.

The content is in a format the resource does not support, by Content-Type or Content-Encoding.

In practice: Sending form data to an endpoint that only accepts application/json.

None of the requested ranges overlap the current extent of the resource.

In practice: Resuming a download past the end of the file.

The expectation in the request's Expect header cannot be met.

In practice: Usually a server that does not support Expect: 100-continue.

Reserved and unused. It comes from the 1998 April Fools' RFC 2324 (I'm a teapot), and RFC 9110 reserves it so it is never assigned.

In practice: Some services return it as a joke or for blocked bots; avoid it in real APIs.

The request was sent to a server that cannot produce a response for that scheme and host.

In practice: Connection reuse across different hostnames with HTTP/2 or HTTP/3.

The content type and syntax are valid, but the server cannot process the instructions. Formerly Unprocessable Entity (WebDAV).

In practice: Validation errors in APIs: well-formed JSON with invalid values.

WebDAV: the resource is locked.

In practice: File servers when another client holds a lock.

WebDAV: the request failed because a request it depended on failed.

In practice: Part of a batch failed, so dependent parts were not applied.

The server will not process a request that might be replayed.

In practice: TLS 1.3 early data (0-RTT) for non-idempotent requests.

The server refuses the request on the current protocol and says which to use in an Upgrade header.

In practice: Forcing a client to a newer protocol version.

The server requires the request to be conditional.

In practice: Prevents lost updates by making clients send If-Match with writes.

The client has sent too many requests in a given time.

In practice: Rate limiting. Include Retry-After so clients know when to try again.

The header fields, individually or together, are too large.

In practice: Oversized cookies are the usual cause.

Access is denied because of a legal demand.

In practice: Content blocked in a country by court order or regulation.

The server hit an unexpected condition that stopped it fulfilling the request.

In practice: Unhandled exceptions. Log the details server-side and never leak stack traces to clients.

The server does not support the functionality needed, such as an unrecognised method.

In practice: Endpoints or methods that are planned but not built.

A gateway or proxy got an invalid response from the upstream server.

In practice: The app behind a load balancer or CDN crashed or returned garbage.

The server cannot handle the request right now, because of overload or maintenance.

In practice: Planned maintenance and load shedding. Send Retry-After; search engines treat 503 as temporary.

A gateway or proxy did not get a response from the upstream server in time.

In practice: Slow database queries or upstream APIs behind a proxy.

The server does not support the HTTP version used in the request.

In practice: Rare outside very old or very new clients.

A server configuration error in transparent content negotiation.

In practice: Very rare.

WebDAV: the server cannot store what is needed to complete the request.

In practice: Disk quota exceeded on file servers.

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

In practice: Bindings that point back to themselves.

Further extensions to the request are required. The RFC is now historic.

In practice: Practically unused.

The client must authenticate to gain network access.

In practice: Captive portals on hotel or airport Wi-Fi.