HTTP Status Codes

The server got the start of the request and tells the client to keep sending the body. You see it with the Expect: 100-continue header, when the client asks permission before uploading a large body.

The server agrees to switch protocols as requested in the client's Upgrade header. The classic example is upgrading an HTTP connection to WebSocket.

A deprecated WebDAV code meaning the server accepted the request and is still working on it, so the client doesn't time out. Rarely used in practice — 103 took its place.

The server sends headers early (usually Link with preload/preconnect) while it prepares the main response. Lets the browser start fetching critical resources sooner.

The request succeeded and the response body carries the useful data. The most common code for GET and any operation that returns a result.

The request succeeded and created a new resource — the typical answer to a POST. Good practice is to return a Location header pointing at the new resource.

The request was accepted but is processed asynchronously and isn't finished yet. Used for background jobs and queues where the result comes later.

A successful response whose metadata was modified by an intermediary (like a proxy) rather than coming straight from the origin server. Very rarely seen.

The request succeeded but there is no body to return — nothing to send back. Unlike 200, it's handy for DELETE or for PUT/PATCH when the client needs no data in return.

The request succeeded and the client is asked to reset the form or view it submitted from. Almost never seen in the wild.

The server returns only part of the resource in response to a Range header. This is what powers resumable downloads and video/audio seeking.

A WebDAV code where the body holds several independent statuses for different operations at once (usually as XML). Useful when one request touches many resources.

A WebDAV code: this element was already listed in a previous part of a Multi-Status response, so it isn't repeated. Niche — you won't meet it outside WebDAV.

The server fulfilled the request and returned a delta-encoding result (RFC 3229) instead of the full resource. Exotic; you basically never hit it in everyday web work.

The requested resource has several representations and the client is invited to pick one. Rarely used in practice — the server usually decides for the client.

The resource has moved for good to the new URL in the Location header. Unlike 302, search engines pass link equity to the new address, so 301 is the choice for a permanent move.

A temporary redirect: the resource currently lives at a different URL but will return to the old one. Unlike 301, no SEO equity is passed; historically browsers switched the method to GET, so use 307 if you must preserve it.

Tells the client to fetch the result from another URL using GET, regardless of the original method. The backbone of the POST/Redirect/GET pattern, so a page refresh won't resubmit the form.

The resource hasn't changed since the client's cached version (via ETag or If-Modified-Since), so no body is sent — use your cache. Saves bandwidth on conditional requests.

Indicates the resource must be accessed through the proxy in the Location header. Deprecated as insecure; modern browsers ignore it.

A temporary redirect like 302, but with a strict guarantee: the method and body are preserved (a POST stays a POST). Use it when the request must not turn into a GET.

A permanent redirect like 301, but it preserves the method and body. Think of it as "301 for POST": the address moved for good and the method must not become GET.

The server couldn't understand the request because of a client-side error: broken syntax, invalid JSON, missing required fields. The generic "you sent something wrong" answer.

The client isn't authenticated: the token is missing, expired, or invalid — the system doesn't know who you are. Unlike 403, the issue is that you haven't identified yourself; log in and retry.

Reserved for future payment use and long mostly unused. These days some APIs return it when payment is needed or a plan's quota is exceeded.

The server knows who you are but refuses access — you lack the rights. Unlike 401, logging in again won't help: you're authenticated, but this operation isn't permitted for you.

No resource exists at this address, and the server doesn't say whether it ever did. Unlike 410, it makes no claim about the resource's fate — maybe it never existed.

The resource exists but the HTTP method doesn't apply to it (e.g. a POST where only GET is allowed). The server must list the allowed methods in the Allow header.

The server can't produce a response in any format the client asked for via the Accept header. For example, the client wants XML but only JSON is available.

Like 401, but you must authenticate with the proxy server rather than the target resource. The proxy expects a Proxy-Authorization header.

The client took too long to send its request, so the server gave up waiting and closed the connection. You can simply retry the request.

The request clashes with the current state of the resource: editing a stale version, or creating something that already exists. Often used for optimistic locking and duplicate detection.

The resource existed but has been permanently removed and won't come back. Unlike 404, this is an explicit "it's gone for good" — a signal for search engines to drop the page.

The server refuses the request because it lacks a Content-Length header. Shows up when the server needs to know the body size up front.

One of the conditions in the request headers (If-Match, If-Unmodified-Since, etc.) failed, so the request was rejected. Guards against overwriting data someone else changed.

The request body is larger than the server is willing to accept (formerly Payload Too Large). Typical when uploading files that are too heavy.

The request URL is longer than the server will process. Usually a GET with a huge number of query-string parameters — switch to POST.

The server can't handle the body format declared in the Content-Type header. For example, XML was sent where only JSON is accepted.

The range requested via the Range header falls outside the resource's size. Happens during resumed downloads when the offset exceeds the file length.

The server can't meet the requirement in the Expect header (usually Expect: 100-continue). Not seen very often in practice.

I'm a teapot, so I can't brew coffee. A joke code from the April Fools' RFC 2324 (HTCPCP); sometimes used as an easter egg or a placeholder response.

The request reached a server not configured to respond to it (the wrong host behind this connection). Relevant in HTTP/2 when connections are reused across domains.

The request syntax is fine, but the data doesn't make sense — business-rule validation failed. Unlike 400 (a malformed request), here the request is understood but semantically wrong; popular in APIs and Laravel.

The resource is locked (a WebDAV code) and can't be changed until the lock is released. Rarely seen outside WebDAV.

The request failed because another request it depended on failed (WebDAV). A niche code.

The server isn't willing to process a request sent too early (TLS 1.3 early data), to avoid replay attacks. It asks the client to retry after the full handshake.

The server refuses to proceed over the current protocol and requires switching via the Upgrade header (e.g. to TLS). It comes with an Upgrade header.

The server requires the request to be conditional (e.g. with If-Match) to avoid a race when changes happen concurrently. Protection against the "lost update" problem.

The client is sending too many requests in a given window — rate limiting kicked in. The server usually adds a Retry-After header telling you when to try again.

The request headers are too large, either in total or individually, and the server refuses them. A common cause is bloated cookies.

Access is blocked for legal reasons — censorship, a government takedown order, or DMCA. The number is a nod to the novel "Fahrenheit 451".

Something broke on the server and it can't explain it more specifically — the catch-all for any unexpected error. Most often it's an unhandled exception in the code.

The server doesn't support the functionality needed to handle this kind of request at all. Unlike 405, the method isn't just disabled for a resource — the server doesn't support it at all.

A server acting as a gateway or proxy got an invalid response from the upstream server. Classic when nginx sits in front of your app and the app returns garbage or crashes.

The server temporarily can't handle the request — overload or maintenance. Usually comes with Retry-After; the condition is temporary and should pass soon.

A gateway or proxy didn't get a response from the upstream server in time. Unlike 502, no response came at all rather than a broken one.

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

A server misconfiguration in content negotiation: the chosen variant itself tries to negotiate, creating a loop. Exotic.

The server ran out of storage space to complete the request (a WebDAV code). Shows up on write operations when the disk or quota is full.

The server detected an infinite loop while processing the request (WebDAV) and aborted. A niche code.

The server needs further extensions to fulfill the request that the request itself doesn't provide. Practically never used.

The client needs to authenticate to gain network access. The classic example is a captive portal — the login screen on public Wi-Fi.