Free HTTP Status Codes Reference

Used for requests with Expect: 100-continue. The server acknowledges that it's willing to receive the body before the client sends it. Rarely seen in modern web apps.

Most commonly used for WebSocket upgrades — the client requests Upgrade: websocket and the server responds 101 to switch.

A WebDAV interim response sent to prevent client timeouts during lengthy operations. Deprecated — modern servers should not send it.

Lets servers send Link headers (preload/preconnect) while the final response is still being prepared, so browsers can start fetching critical assets sooner.

The standard success response. The meaning depends on the HTTP method: GET → resource returned, POST/PUT → action completed.

Common after a POST. The response should include a Location header pointing to the new resource's URL.

For async operations — the server is queuing the work. The client should poll a status endpoint or check back later.

The request succeeded, but an intermediary (such as a caching or transforming proxy) altered the payload from the origin server — for example, recompressing images. Rare in practice.

Often used for DELETE operations or PUT updates that don't need to return a body. The client should not navigate away from the current page.

Like 204, no body is returned — but the client is additionally told to reset the form or view that produced the request (e.g. clear the form fields for the next entry).

Response to a Range request. Used by video players and download managers to resume interrupted downloads or stream large files.

WebDAV: an XML body reports the outcome of several sub-operations independently — e.g. a batch move where some items succeeded and others failed.

WebDAV: used inside 207 Multi-Status responses to avoid repeatedly listing members of the same collection when bindings create loops.

Delta encoding: the server returns a diff against a previous version instead of the full resource, saving bandwidth. Very rarely implemented.

The server offers multiple options (e.g. different formats or languages) and the client should choose one. Rarely used, because automatic content negotiation usually handles this.

Use for permanent URL changes — search engines will update their index. SEO authority transfers to the new URL.

Indicates the redirect is not permanent. Caching is less aggressive than 301. Use for things like 'login required, redirecting to /login'.

Used after POST submissions — the response says 'your POST worked, see this GET URL for the result'. Browsers always GET the new URL.

Response to a conditional request (with If-None-Match or If-Modified-Since headers). Saves bandwidth — no body is returned.

If the original was POST, the redirect also uses POST. Modern alternative to 302 when method preservation matters.

Modern replacement for 301 when you want POST requests to remain POST after the redirect.

Common causes: malformed JSON in body, invalid query parameters, or missing required fields. Check the request body and headers.

The client must include authentication credentials (Authorization header, cookie, token). 'Unauthorized' is a misnomer — it really means 'unauthenticated'.

Originally intended for digital payments. Modern usage: APIs sometimes return 402 when a user has exceeded their paid quota.

Different from 401 — the user IS logged in, but their account doesn't have permission for this resource. Check role/permissions logic.

Either the URL is wrong, the resource was deleted, or it never existed. Servers sometimes return 404 to hide that a 403 would be more accurate.

For example, a GET request to an endpoint that only accepts POST. The response should include an Allow header listing valid methods.

The client asked for a content type, language, or encoding (via Accept, Accept-Language, Accept-Encoding) the server cannot satisfy. Many servers skip strict negotiation and return a default instead.

Like 401, but issued by a proxy: the client must send Proxy-Authorization credentials. Seen on corporate networks with authenticating proxies.

The client took too long to send the request body or kept the connection idle. Try the request again.

Typically returned for concurrent edit conflicts or duplicate resource creation (e.g., creating a user with an email that already exists).

Stronger than 404 — the server explicitly knows the resource USED to exist but has been permanently removed. Search engines will deindex.

The request was rejected because it lacked a Content-Length header and the server refuses bodies of unknown size. Add the header and retry.

Returned when conditional headers like If-Match or If-Unmodified-Since fail — typically optimistic locking: someone else changed the resource since your version. Refetch and retry.

Common when uploading large files. Server config (nginx, apache) sets a max body size. Check the server's configuration.

Usually caused by very long query strings (e.g. encoding data in a GET). Switch to a POST body, or raise the server limit if you control it.

For example, sending application/xml to a server that only accepts application/json. Set the Content-Type header correctly.

The Range header asks for a portion the file does not have — e.g. resuming a download past the end of the file. The response should include Content-Range with the actual size.

Sent when the server does not support Expect: 100-continue. Some clients send this header by default on large POSTs; disabling it usually resolves the error.

An April Fool's joke from 1998 (RFC 2324). Some real APIs use it for jokes or to mark deprecated endpoints. Not for production use.

Common with HTTP/2 connection reuse: the request reached a server that is not configured for the target hostname. The client should retry on a new connection.

For example, JSON parsed correctly but a required field was missing, or a field value was out of range. Common in REST API validation responses.

WebDAV: the source or destination resource is locked by another client, so the operation cannot proceed. Wait for the lock to be released or break it with the proper token.

WebDAV: in a chain of dependent operations, an earlier action failed, so this one was not performed. Look at the earlier failure for the root cause.

Related to TLS 1.3 0-RTT (early data): the server will not risk processing a possibly replayed request. The client should retry after the handshake completes.

The server refuses to serve the request over the current protocol but will after an upgrade — the response includes an Upgrade header naming the required protocol.

The server demands conditional headers (like If-Match) to prevent lost-update conflicts. Fetch the resource, capture its ETag, and resend with If-Match.

Slow down. The response should include a Retry-After header indicating when to try again. Common with APIs that have request quotas.

Either one header or the total header size exceeds the limit — most often caused by oversized cookies. Clear cookies or reduce what your app stores in them.

The resource is blocked for legal reasons — censorship, court orders, or regional regulations. The number is a nod to the novel Fahrenheit 451.

A generic catch-all for server-side errors. Check server logs for the actual cause: unhandled exception, database error, etc.

For example, the server doesn't recognize the HTTP method. Rare in practice — more often you'll see 405.

Common in microservice architectures. Your load balancer or reverse proxy got a malformed response from the backend service.

Either down for maintenance or overloaded. The response should include a Retry-After header. Often returned during deployments.

The backend service didn't respond fast enough. Check upstream service health and timeout configurations.

The major HTTP version of the request is not supported by the server. Almost never seen with modern clients.

Transparent content negotiation ended in a loop: the chosen variant is itself configured to negotiate. Indicates a server configuration error.

WebDAV-specific in origin but sometimes used by general servers. Means the server can't save the request because of storage constraints.

WebDAV: processing a Depth: infinity request entered a loop (e.g. circular bindings). The operation was terminated.

From the obsolete HTTP Extension Framework: the server needs more information before it can fulfill the request. Effectively unused on the modern web.

Used by captive portals (hotel/airport WiFi) to indicate the user must log in to the network before accessing external sites.