Search every HTTP status code with its meaning, typical cause and correct usage.
Showing all 63 status codes.
The request was received and the process is continuing. These are interim responses; another response always follows.
The request headers were received and are acceptable, so the client should go ahead and send the request body.
When to send it: In reply to a request carrying `Expect: 100-continue`, once the headers have been checked and nothing about them requires rejecting the upload.
The server agrees to change the protocol on this connection to the one named in the request's Upgrade header.
When to send it: Completing a WebSocket handshake, or an HTTP/1.1 to HTTP/2 upgrade over cleartext. After this response the connection stops speaking HTTP/1.1.
A WebDAV interim response meaning the server has accepted the request but has not finished it, sent to stop the client timing out.
When to send it: Rarely. It was defined for long-running WebDAV methods and was dropped in the revised WebDAV spec; 103 Early Hints covers the useful case better.
An interim response that carries Link headers so the browser can start preloading assets before the real response is ready.
When to send it: When the final response will take time to generate but you already know which stylesheet, font or script the page needs. Send the hints, then the 200.
The request was received, understood and accepted.
The request succeeded and the response body carries the result.
When to send it: The default success response for GET, HEAD, PUT, PATCH, POST and DELETE whenever a representation is returned. For GET that is the resource; for POST it is the result of the action.
The request succeeded and one or more new resources exist as a result.
When to send it: After a POST or PUT that creates something. Include a Location header pointing at the new resource; the body should be its representation.
Often confused: A POST that creates nothing — a search, a calculation, a webhook receipt — should return 200 or 204, not 201.
The request was accepted for processing but nothing has happened yet, and it may still fail.
When to send it: When work is queued: a batch import, a video transcode, an email send. Return a way to check progress, because the client will never learn the outcome otherwise.
The request succeeded, but a proxy modified the payload it received from the origin server.
When to send it: Almost never by an application. It is for transforming proxies that, for example, downscale images or strip tracking parameters.
The request succeeded and there is deliberately no body. Any headers still apply.
When to send it: A DELETE that leaves nothing to show, a PUT where the client already holds the new state, or a form submission that should not navigate. A 204 must not carry a body — sending one breaks HTTP framing.
Often confused: Use 204 rather than 200 with an empty body: 200 promises a representation, so clients will try to parse the nothing they receive.
The request succeeded and the client should clear the form or document view that produced it.
When to send it: In a data-entry workflow where the user enters one record after another. It predates single-page applications and is rare now.
The response carries only the byte ranges the client asked for in its Range header.
When to send it: Serving a resumed download or a video seek. Include Content-Range, and make sure the ranges you send are the ones requested.
The body is an XML document containing a separate status for each of several independent operations.
When to send it: WebDAV only, for methods such as PROPFIND that act on a collection where each member can succeed or fail individually.
Inside a 207 body, marks a collection member whose result was already listed earlier in the same response.
When to send it: WebDAV binding scenarios, to avoid repeating the same subtree over and over when resources are linked into several places.
The response is the result of applying one or more instance manipulations — typically a delta — to the current resource.
When to send it: Delta encoding, where the server sends only what changed since the client's cached copy. Support is effectively nonexistent outside specialist deployments.
Further action is needed to complete the request, usually following a Location header.
The request maps to more than one resource and the server is offering the client a list to pick from.
When to send it: Rarely, because there is no standard format for the list. Content negotiation normally happens through Accept headers instead.
The resource has a new permanent URL, given in the Location header. Clients, caches and search engines should update their references.
When to send it: A URL structure change, an http to https move, a domain migration — anything you never intend to undo. It is cached indefinitely by default, so it is very hard to take back.
Often confused: 301 vs 308: both are permanent, but 301 historically caused clients to convert a POST into a GET, and browsers still do. 308 forbids that conversion. For a page, 301 is fine; for an API endpoint that accepts POST, use 308.
The resource is temporarily at a different URL. The original URL stays canonical and should be used for future requests.
When to send it: Short-lived redirects: maintenance pages, A/B splits, sending a user to a login page. Do not use it for a move you intend to keep.
Often confused: 302 vs 307: the specification always said the method must not change, but browsers turned POST into GET anyway, so the spec gave up and defined 307 to mean "temporary, and really do keep the method". If a POST must stay a POST, send 307.
The result of the request is at another URL, which should be fetched with GET regardless of the original method.
When to send it: The Post/Redirect/Get pattern. After a successful form POST, 303 to the result page so that reloading it does not resubmit the form.
The client's cached copy is still current, so no body is sent. It is a redirect to the cache rather than to another URL.
When to send it: When a conditional GET arrives — If-None-Match matching the current ETag, or If-Modified-Since at or after the last modification. Send the caching headers, never a body.
The resource must be accessed through the proxy named in the Location header.
When to send it: Never. It was deprecated for security reasons: it let any server redirect a client through a proxy of the server's choosing.
Reserved. An early draft used it for "Switch Proxy"; the code is kept reserved so nothing else claims it.
When to send it: Never. It has no defined meaning and no client implements it.
Same as 302, with the method and body guaranteed to be preserved: a POST is re-sent to the new URL as a POST.
When to send it: Temporary redirects for APIs and anything non-GET. It is also what HSTS preloading does internally when upgrading a request to https.
Often confused: If you ever redirect a POST and the target receives a GET with no body, you sent 302 or 303 where you needed 307.
Same as 301, with the method and body guaranteed to be preserved. The new URL should replace the old one everywhere.
When to send it: Permanently moving an endpoint that accepts POST, PUT or PATCH. Like 301, it is cached aggressively — deploy it only once you are sure.
Often confused: 308 vs 301: functionally identical for GET traffic. Search engines treat both as a permanent move and pass ranking signals the same way, so pick based on whether non-GET methods are involved.
The request was wrong: bad syntax, missing credentials, a resource that is not there. Repeating it unchanged will fail the same way.
The server refuses to process the request because something about it is malformed — unparseable JSON, an illegal header, a bad query string.
When to send it: When the request itself is broken at the syntax level. If the syntax is fine but the values are wrong, 422 is more precise.
Often confused: It is often used as a catch-all for every client mistake. That works, but it tells the caller nothing; prefer the specific code where one exists.
Authentication is required and has either not been supplied or has failed. Despite the name, this is about identity, not permission.
When to send it: No credentials, an expired token, a wrong password. The response must include a WWW-Authenticate header naming the scheme, which is the part almost every API forgets.
Often confused: 401 vs 403: 401 means "I do not know who you are — try authenticating again". 403 means "I know exactly who you are, and you still cannot do this". Retrying with a fresh token can fix a 401; it will never fix a 403.
Reserved for future use; there has never been a standard payment protocol behind it.
When to send it: Some APIs use it for "your plan has run out" or "this account is in arrears". That is a reasonable convention but not a specified behaviour, so document it.
The server understood the request and is refusing it. Authenticating differently will not help.
When to send it: A valid user without the required role, an IP blocked by a firewall, a directory listing that is switched off. There is no obligation to explain why.
Often confused: 403 vs 404: revealing that a resource exists but is off limits can itself be a leak. Many systems deliberately return 404 for resources the caller may not know about — GitHub does this for private repositories.
There is no resource at this URL. The server will not say whether there ever was one or ever will be.
When to send it: An unknown path, a deleted record, a typo in an ID. Send it with a useful HTML page for browsers and a machine-readable body for APIs.
Often confused: 404 vs 410: 404 says nothing about the future, 410 says the resource is deliberately gone for good. Search engines drop a 410 URL faster than a 404 one.
The URL exists but does not support this method — a POST to a read-only endpoint, a DELETE where only GET is implemented.
When to send it: When the path is routable but the verb is not. The response must include an Allow header listing the methods that do work.
Often confused: If the URL itself is unknown, that is 404. A 405 is a promise that the resource exists.
Nothing the server can produce matches the client's Accept, Accept-Language or Accept-Encoding headers.
When to send it: Rarely. Returning your best available representation is usually friendlier than refusing, and the spec explicitly allows that.
Like 401, but the credentials are demanded by an intermediate proxy, not the origin server.
When to send it: By a proxy, together with a Proxy-Authenticate header. Seeing one from an API usually means a corporate proxy is intercepting the call.
The client opened a connection but did not send a complete request in the time the server was willing to wait.
When to send it: When an idle or half-sent request is being closed. It is a 4xx because the slow party was the client.
Often confused: 408 is the client being slow to send; 504 is an upstream server being slow to answer. They are frequently mixed up in dashboards.
The request is valid but clashes with the current state of the resource, and the clash is something the client could resolve and retry.
When to send it: A duplicate email on signup, an edit against a stale version, deleting a resource that still has children. Say in the body what conflicts.
Often confused: 409 vs 422: 409 is about state — the same request would have worked a moment ago, or will work once something changes. 422 is about the content — the request will never work as written, no matter what the server state is.
The resource used to exist here and has been permanently removed. No forwarding address.
When to send it: Retired API versions, deleted accounts, expired campaign URLs — anywhere you want crawlers and clients to stop asking.
The server refuses a request with a body but no Content-Length header.
When to send it: When you cannot accept chunked transfer encoding and need to know the size up front, typically to enforce a limit before reading.
A conditional header such as If-Match or If-Unmodified-Since evaluated to false, so the request was not applied.
When to send it: Optimistic concurrency: the client sent the ETag it last saw, the resource has changed since, and applying the write would silently overwrite someone else's edit.
Often confused: On a conditional GET a failed precondition gives 304; on a write it gives 412. Same mechanism, different outcome.
The request body is bigger than the server is willing or able to process.
When to send it: An upload over your limit. If the limit is temporary, add Retry-After. Nginx returns this as "413 Request Entity Too Large" — the name changed in RFC 9110, the meaning did not.
The request target is longer than the server is prepared to interpret.
When to send it: Normally hit accidentally, when a form that should POST uses GET and pushes everything into the query string. Common server limits sit around 8 KB of request line.
The body's Content-Type is one this endpoint does not accept.
When to send it: A form-encoded body sent to a JSON-only endpoint, or a missing Content-Type header. List what you do accept in the response body.
Often confused: 415 is about the format of what was sent; 406 is about the format the client asked to receive.
None of the byte ranges requested overlap the resource — usually a start past the end of the file.
When to send it: When a resumed download asks for bytes that no longer exist because the file changed. Include Content-Range with the true size so the client can restart.
The expectation in the request's Expect header cannot be met by this server.
When to send it: When a client sends `Expect: 100-continue` and something in the chain will not honour it, or sends an expectation the server does not recognise.
From the 1998 April Fools' Hyper Text Coffee Pot Control Protocol: the server is a teapot and permanently refuses to brew coffee.
When to send it: Never in earnest. RFC 9110 reserves the code precisely so nobody can reassign it, because too many frameworks implement it as a joke. It is fine as an easter egg, terrible as an error contract.
The request reached a server that is not configured to produce a response for the authority in it.
When to send it: An HTTP/2 artefact. Connections are reused across hostnames that share a certificate, so a request for one host can arrive on another's connection; 421 tells the client to open a fresh one.
The syntax is fine and the content type is understood, but the instructions inside cannot be followed — the data fails validation.
When to send it: Field-level validation failures: an email without an @, an end date before the start date, a required field left empty. Return the specific field errors.
Often confused: 422 vs 400: if JSON.parse would fail, it is 400. If it parses cleanly and then fails your schema, it is 422. Some APIs use 400 for both, which is legal but loses the distinction.
The resource is locked and the request would modify it.
When to send it: WebDAV, where a client holds an explicit lock token on a file or collection.
The request failed only because an earlier request it depended on failed.
When to send it: WebDAV, inside a 207 response, for operations skipped because a previous step in the same atomic request did not succeed.
The server will not risk processing a request that arrived in TLS 1.3 early data, because early data can be replayed by an attacker.
When to send it: When 0-RTT is enabled and a non-idempotent request arrives in early data. The client should retry once the handshake is complete.
The server refuses this request on the current protocol and names a better one to switch to.
When to send it: Rejecting plaintext HTTP/1.0, or requiring a WebSocket upgrade. The response must carry an Upgrade header saying what to use.
The server requires the request to be conditional, and this one was not. It refuses unconditional writes on principle.
When to send it: To prevent the lost-update problem: demand If-Match so two clients cannot both overwrite the version they last read.
Often confused: 428 means "you forgot to send a precondition"; 412 means "you sent one and it failed".
The client has sent too many requests in a given period and is being rate limited.
When to send it: Whenever a quota is exceeded. Always include Retry-After — without it every client will hammer you with its own guess about when to come back.
The headers are collectively or individually too large to process.
When to send it: Most often an oversized Cookie header after years of accumulated cookies on a domain. Typical server limits are 4–8 KB per header.
Access is denied because of a legal demand — a court order, a takedown notice, a statutory block.
When to send it: When the resource exists but you are compelled to withhold it. Include a Link header with rel="blocked-by" identifying who imposed the block. The number references Fahrenheit 451.
The request looked valid but the server could not fulfil it. The same request may succeed later.
The server hit an unexpected condition and cannot be more specific. It is the catch-all for unhandled exceptions.
When to send it: When code threw and nothing caught it. Log the detail with a correlation ID, return the ID and nothing else — a stack trace in a 500 body is a genuine information leak.
Often confused: If the failure is actually a client mistake, a 500 sends the caller off debugging your server instead of their request. Check the 4xx list first.
The server does not support the functionality needed to fulfil the request at all.
When to send it: An unrecognised method, or a documented endpoint that is not built yet. It is about the server's capability, so it is a 5xx even though the trigger came from the client.
Often confused: 501 means the server does not know this method anywhere; 405 means this particular resource does not accept it.
A proxy or load balancer got an invalid — or no — response from the server it forwarded to.
When to send it: Emitted by the intermediary, not by your application. In practice it means the upstream process crashed, refused the connection, or spoke something that was not valid HTTP.
Often confused: 502 is an upstream that answered badly; 504 is an upstream that did not answer in time; 503 is this server saying it is out of service.
The server is temporarily unable to handle the request — overloaded, or deliberately down for maintenance.
When to send it: Planned maintenance and load shedding. Send Retry-After, because it is the one signal that stops search engines de-indexing a site during a short outage.
A proxy did not get a response from the upstream server within its time limit.
When to send it: By the intermediary when an upstream call runs long. The usual causes are a slow query, a deadlock, or a downstream dependency of the upstream itself timing out.
Often confused: 504 is the proxy giving up on a server; 408 is a server giving up on a client that never finished sending.
The major HTTP version used in the request is one the server refuses to support.
When to send it: Very rarely. A server that declines HTTP/1.0 or is given a nonsense version string in the request line.
A content-negotiation misconfiguration: the chosen variant is itself set up to negotiate, so the process never terminates.
When to send it: Only by servers implementing transparent content negotiation, as a configuration error.
The server cannot store the representation needed to complete the request.
When to send it: WebDAV, when a PUT or COPY would exceed the available quota or disk. Some object stores reuse it for quota errors.
The server stopped an operation because it found an infinite loop while processing it.
When to send it: WebDAV, when bindings make a collection contain itself and a depth-infinity request would never end.
The request needs further extensions declared in advance before the server will fulfil it.
When to send it: Effectively never. The HTTP extension framework it belongs to was made obsolete and never saw real deployment.
The client must authenticate to gain network access — this response comes from the network, not from the site being requested.
When to send it: By a captive portal on hotel or airport Wi-Fi, so that software can recognise an interception instead of concluding the API is broken. Intercepting proxies should use this rather than silently returning a login page with 200.
No status code matches that search. Try a number, a reason phrase such as “gateway”, or a symptom such as “rate limit”.
This is the complete HTTP status code registry — 63 codes from 100 to 511 — with each one
explained in terms of the decision you are actually making: what the code asserts, when a
server is right to send it, and which other code it is usually mistaken for. Search accepts a
number, a reason phrase, or the symptom you are looking at: type etag and you get
304 and 412.
Partial numbers work as prefixes, so 42 lists the whole 42x run together —
useful when you remember the shape of a code but not the digits.
A client PUTs an updated record whose version is stale:
HTTP/1.1 409 Conflict
Content-Type: application/problem+json
{"title":"Version conflict","current":42,"submitted":39}409 is right because the request is well-formed and would have succeeded a moment ago: the client can re-read, merge and retry. Had the body simply failed validation — a negative quantity, a malformed date — nothing about the server's state would change the outcome, and the correct answer would be 422.
The first digit is a contract with every intermediary between client and server, and it matters more than the remaining two. A 4xx tells caches and clients that retrying the identical request is pointless; a 5xx invites a retry with backoff. That is why classifying a client mistake as 500 is worse than merely inaccurate — it invites a retry storm and sends the caller to debug your infrastructure instead of their payload.
Cacheability follows the same rule. By default 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 and 501 are cacheable by a shared cache even without explicit headers, which is how a 404 served during a botched deploy can outlive the deploy by hours.
The reason phrase — the “Not Found” after the 404 — is decorative, and HTTP/2 and HTTP/3 dropped it from the wire entirely, so anything parsing it breaks on a modern connection. Codes outside the registry are legal: a client must treat an unknown 4xx as 400 and an unknown 5xx as 500, which is what lets Cloudflare use 520–527 and nginx use 444 without breaking anyone. And 418 is reserved rather than free precisely because so many frameworks implemented the teapot joke that reassigning the number became impossible.
401 says the request carried no usable credentials and that repeating it with them may succeed — RFC 9110 §15.5.2 requires the response to include a WWW-Authenticate header naming the scheme, and a 401 without one is malformed. 403 says the server worked out who is calling and is refusing anyway, so re-authenticating changes nothing. A signed-in user reaching into another tenant’s record gets 403.
Only the guarantee about the method. Clients have always been permitted to turn a POST into a GET when following 301 or 302, and in practice browsers do. 307 and 308, defined in RFC 9110 §15.4.8 and §15.4.9, forbid that: the method and body are replayed unchanged. A moved HTML page can stay on 301, but an API endpoint that accepts POST must move with 308 or the body silently disappears.
410 asserts that the removal is deliberate and expected to be permanent (RFC 9110 §15.5.11); 404 says only that nothing was found at this address right now. Google documents treating the two almost identically, with a 410 leaving the crawl schedule a little sooner, so the distinction pays off mainly on a bulk removal of thousands of URLs. If the content might return, 404 is the honest answer.
It is nginx’s own invention — client closed request — and it never travels over the wire, because the caller already hung up before the response existed. A cluster of them means clients are timing out ahead of your upstream: a mobile app with a 10-second deadline in front of a 12-second query. It appears in no registry, so nothing else sends or interprets it.