HTTP status code reference

The server has read the start of the request and wants the rest of it.

A client that expects to send a large body can send `Expect: 100-continue` with the headers and wait before sending the body. A 100 means the server has not rejected the request so far and wants the content; the client sends the body and discards the 100. If the request carried no 100-continue expectation, the client just ignores the interim response.

The server agrees to change protocol on this connection, as the client asked.

The client asks with an Upgrade header and the server answers 101 with its own Upgrade header naming the protocol that takes over. This is how a WebSocket handshake completes, which is where most developers see it. After the 101, the connection no longer carries HTTP messages.

A WebDAV server is still working on a request that takes a long time.

RFC 2518 defined it so a server could tell the client it has the complete request but has not finished acting on it, suggested for anything taking longer than about 20 seconds. It keeps a client from timing out during a slow WebDAV operation. RFC 4918, which obsoletes RFC 2518, removed the code and states that its registration should continue to reference RFC 2518.

Registry note. Removed by RFC 4918, the current WebDAV specification; the registry still cites RFC 2518.

Header fields the final response will probably carry, sent early so the browser can start fetching.

The server sends a 103 with Link headers before it has finished building the real response, so the browser can start preloading stylesheets, scripts or fonts. The hints are speculative: they do not replace the headers on the final response, and evaluating them must not change how that response is processed. A client that does not understand 103 simply waits for the final status.

An interim response telling the client that this upload can be resumed if it breaks.

It belongs to the in-progress resumable uploads work in the HTTP working group, where the server answers an upload with 104 and a handle the client can use to ask how much arrived and carry on from there. Nothing is standardised yet. The registry holds the code as a temporary registration, so treat it as experimental rather than something to implement against.

Registry note. Temporary registration from an Internet-Draft; the registry entry expires 2026-11-13.

The request succeeded, and the response body is the result.

What the body contains depends on the method: the resource itself for GET, the result of the action for POST, the status of the action for PUT and DELETE. A 200 is expected to carry content unless the framing says the content has zero length; if a successful request has nothing to return, 204 is the better answer. 200 responses are heuristically cacheable unless cache headers say otherwise.

The request succeeded and one or more new resources now exist.

Send it from a POST or PUT that created something, with a Location header pointing at the primary new resource; if there is no Location, the new resource is the request URI itself. The body usually describes and links to what was created. Use 200 instead when the request succeeded without creating anything.

The request was accepted for processing, but nothing has happened yet.

It is deliberately noncommittal: the work is queued, might be rejected later when it actually runs, and HTTP has no way to send you the eventual result. Use it when a job runs out of band and you do not want to hold the connection open. The body should describe the current state and point at a status endpoint the client can poll.

The request succeeded, but a proxy changed the body on the way back.

A transforming proxy that rewrites a response, for example by recompressing images, sends 203 instead of 200 so the recipient knows the content is not what the origin server sent. It matters mostly for caching, since the transformed copy may only be valid along the same path. It is rare on the modern web.

The request succeeded and there is deliberately nothing in the response body.

The headers still describe the target resource after the action was applied, so a 204 to a PUT can carry the new ETag. It is the usual answer to a successful DELETE, and to a save action where the client should stay where it is. A 204 ends at the end of the header section and cannot contain content or trailers, so do not attach a body.

The request succeeded and the client should clear the form it was submitted from.

It was designed for data entry: the user fills in a form, submits it, and the client resets the fields ready for the next entry. A server must not send content with a 205. Almost nothing uses it now, since applications handle the reset themselves.

The server is returning only the byte ranges the client asked for.

It answers a request with a Range header, and it is what makes resumable downloads and video seeking work. The client must read Content-Type and Content-Range to see which parts arrived and whether more requests are needed. A server is free to return fewer ranges than asked for, or to ignore Range entirely and send a plain 200.

One WebDAV response carrying a separate status for each of several resources.

A WebDAV method such as PROPFIND acts on many resources at once, so the body is an XML multistatus document with a status per resource. The 207 itself says nothing about whether the individual operations worked. Outside WebDAV you will rarely meet it.

A WebDAV collection was listed earlier in the same multistatus response, so it is not repeated.

When several bindings point at the same collection, a deep PROPFIND would otherwise enumerate its members again and again. The first binding is reported with 200 and the rest with 208, with no entries for their descendants. It only appears inside a 207 body, and only for `Depth: infinity` requests.

The response is the result of applying delta encoding to the resource.

The client asks with an A-IM header listing instance manipulations, and the server answers 226 with the result rather than the whole resource, typically a diff against a copy the client already has. The response must carry an ETag for the current instance. Delta encoding in HTTP never saw wide deployment.

The resource has several representations and the client has to pick one.

The server lists the alternatives so the user or the user agent can choose, and may add a Location header for its own preferred choice. HTTP never standardised a format for that list, which is the main reason the code is barely used. It is heuristically cacheable.

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

Use it when an address has changed for good and you want links and search engines updated. RFC 9110 notes that for historical reasons a user agent may change the request method from POST to GET when following it, and says to use 308 instead if that is undesirable. A 301 is heuristically cacheable, so clients can remember it for a long time; be sure before you send one.

The resource is temporarily at a different URL; keep using the original one.

It is the default redirect of most web frameworks. RFC 9110 carries the same historical note as for 301: a user agent may change the request method from POST to GET, and 307 exists for when that is undesirable. Because the move is temporary, clients should keep requesting the original URI.

Look at this other URL with a GET to see the result of what you just did.

It is the post/redirect/get pattern in one status code: a POST finishes, the server answers 303, and the client issues a GET against the Location URL so the result has its own bookmarkable, cacheable address. The redirect target is explicitly not equivalent to the original URI. It applies to any method, and switching to GET is the defined behaviour rather than a historical accident.

Your cached copy is still good, so nothing is being sent.

It answers a conditional GET or HEAD, one carrying If-None-Match or If-Modified-Since, whose condition turned out false, meaning the copy the client already has is current. The server must repeat the header fields that matter for caching, such as ETag, Date, Cache-Control and Vary, and must send no body. The client reuses its stored representation as if it had received a 200.

A withdrawn code that once told the client to repeat the request through a proxy.

RFC 9110 states that it was defined in a previous version of the specification and is now deprecated. Browsers never implemented it consistently, and letting a server redirect a client onto an arbitrary proxy was a security problem. Do not send it, and treat it as an error if you receive it.

Registry note. Deprecated by RFC 9110 §15.4.6.

A code from an old draft that is no longer used and is reserved.

RFC 9110 §15.4.7: "The 306 status code was defined in a previous version of this specification, is no longer used, and the code is reserved." It has no reason phrase of its own in the registry, which lists it as "(Unused)". It appears in lists like this one only so the number is accounted for.

Registry note. Unused and reserved. The registry lists the code with no reason phrase.

Temporarily somewhere else, and the client must keep the same method and body.

RFC 9110 says the user agent MUST NOT change the request method if it redirects automatically, so a POST stays a POST. That is the whole difference from 302. Use it for temporary moves where the method matters, and keep requesting the original URI in future.

Permanently somewhere else, and the client must keep the same method and body.

It is 301 without the method rewriting, defined the same way as 307 but permanent. RFC 9110 notes the code is much younger than its siblings, dating from June 2014, so it might not be recognised everywhere. Like 301 it is heuristically cacheable and can be remembered for a long time.

The server will not process the request because something about it looks wrong.

The RFC gives malformed syntax, invalid message framing and deceptive routing as the examples, so it is properly about the request itself rather than the data inside a well-formed body. In practice it is also the catch-all many APIs return for failed validation. Repeating the same request will not help; fix the request first.

You are not authenticated, or the credentials you sent were not accepted.

The name is misleading: this is about authentication, not permissions. A server sending 401 MUST include a WWW-Authenticate header with at least one challenge, and a client may retry with a new or replaced Authorization header. If credentials were sent and still got 401, they were refused.

Reserved for future use; there is no defined behaviour.

RFC 9110 says only that the code is reserved for future use. No payment mechanism was ever standardised around it. Some APIs use it for billing problems, but that is a private convention, so clients cannot rely on any particular meaning.

Registry note. Reserved for future use.

The server understood the request and refuses to do it.

If credentials were provided, the server considers them insufficient, and the client should not repeat the request with the same ones. A request can also be forbidden for reasons that have nothing to do with credentials. A server that does not want to admit the resource exists may answer 404 instead.

There is nothing at this address, or the server will not say that there is.

It says nothing about whether the absence is temporary or permanent. RFC 9110 prefers 410 when the server knows the condition is likely permanent. It is heuristically cacheable, which surprises people whose 404s stick around in a CDN.

The server knows this method but the resource does not support it.

A POST to a read-only endpoint is the usual cause. The origin server MUST include an Allow header listing the methods the resource does support, so the response tells the client what to send instead. If the server does not recognise the method at all, 501 is the right answer.

Nothing the server can send matches the Accept headers the client sent.

It comes from proactive content negotiation: the client restricted the media types, languages or encodings it will take, and the server has no matching representation and will not send a default. The server should list the available alternatives in the body. Many servers prefer to ignore the negotiation headers and send their default representation instead.

Like 401, but it is the proxy that wants credentials, not the destination server.

The proxy MUST send a Proxy-Authenticate header with a challenge, and the client retries with Proxy-Authorization. It is a normal sight on corporate networks that route traffic through an authenticating proxy. Nothing about the target server is implied.

The server gave up waiting for the rest of the request.

It means the complete request never arrived in the time the server was prepared to wait, often because an idle keep-alive connection was closed. A client with a request still in flight may repeat it, on a new connection if the old one is no longer usable. It is about receiving the request, not about how long the server took to answer, which is 504.

The request clashes with the current state of the resource.

It is most likely on a PUT, for example when the version being written conflicts with a change someone else made. It is used where the user could resolve the conflict and try again, so the body should carry enough detail to work out what clashed. APIs also use it for duplicate-creation attempts such as an already registered email address.

It was here, it is deliberately gone, and it is not coming back.

Use it when you know the removal is permanent and you want remote links taken down; use 404 when you do not know. It suits expired promotions, retired API versions and pages removed on purpose. It is heuristically cacheable, and there is no obligation to keep serving it forever.

The server refuses a request whose body has no Content-Length.

It appears when a client streams a body with chunked transfer encoding to a server that insists on knowing the size up front. The client may repeat the request with a valid Content-Length header. Buffering the body to measure it is the usual fix.

A condition attached to the request was false, so the server did not act.

It answers a request carrying If-Match, If-Unmodified-Since or a similar header whose condition failed when tested on the server. That is how optimistic concurrency works: the write is refused because the resource changed since you read it. Fetch the current version, reapply your change and retry.

The request body is bigger than the server is willing to handle.

Upload limits in web servers, proxies and API gateways produce it constantly. The server may close the connection rather than read the rest. If the limit is temporary the server should send Retry-After; otherwise send less, or use an upload endpoint built for large files. RFC 9110 renamed it from "Payload Too Large", so older tools may show that phrase.

The request URL is longer than the server will interpret.

RFC 9110 calls it rare and blames a POST wrongly converted to a GET with a long query string, a redirect loop that keeps appending to the path, or an attacker probing for buffer problems. Move the data into a request body. It is heuristically cacheable.

The body is in a format this endpoint does not accept.

The problem may be the Content-Type, the Content-Encoding, or what the server finds when it inspects the data. Sending form-encoded data to an endpoint that only takes JSON is the everyday cause. The server can answer with Accept or Accept-Encoding to say what it would have taken.

None of the requested byte ranges can be served.

It usually means the range starts past the end of the resource, but a server may also refuse an excessive number of small or overlapping ranges as a denial-of-service risk. A server answering a byte-range request should include Content-Range with the current length so the client can recalculate. Clients cannot count on receiving it, since servers are free to ignore Range and send a full 200.

The server cannot meet the expectation in the request Expect header.

In practice the only expectation in use is `Expect: 100-continue`, so this is what a server that will not handle it can answer. At least one server on the path could not satisfy it. Retry without the Expect header.

The teapot joke code, reserved so nothing else can claim the number.

RFC 9110 §15.5.19 explains that RFC 2324 was an April 1 RFC that lampooned the abuse of HTTP, that its application-specific 418 "has been deployed as a joke often enough for the code to be unusable for any future use", and that 418 is therefore reserved in the registry. The registry lists it as "(Unused)" with no reason phrase. The RFC adds that it could be reassigned in future if the 4xx range runs short.

Registry note. Unused and reserved. The registry lists the code with no reason phrase.

This server cannot answer for the host in the request.

It is sent when a request arrives at a server not configured for that origin, or over a connection whose context does not match, which happens when HTTP/2 reuses one connection for several hostnames sharing a certificate. A client may retry over a different connection even when the method is not idempotent. A proxy must never generate it.

The body parsed fine but the instructions in it cannot be carried out.

The server understood the content type, so 415 does not apply, and the syntax is correct, so 400 does not fit either; the content is just semantically wrong. It is the code most APIs use for validation failures on a well-formed JSON body. RFC 9110 renamed it from WebDAV's "Unprocessable Entity", which is still the phrase many libraries print.

The WebDAV resource involved in the request is locked.

Either the source or the destination of the method is locked, and the response should carry a precondition or postcondition code such as `lock-token-submitted`. Supplying the right lock token in the If header is the way through. It belongs to WebDAV.

This part of the request failed because another part it depended on failed.

When one command in a WebDAV PROPPATCH fails, the rest report 424 rather than being attempted. It marks work that was skipped, not work that was tried and broke. Fix the underlying failure and resend.

The server will not risk processing a request that arrived in TLS early data.

TLS 1.3 lets a client send data in the first flight, before the handshake completes, which saves a round trip but allows an attacker to replay that data. A server that does not want to take the risk answers 425, and the user agent is expected to retry once the handshake is done, never again in early data. A server should only send it when the request came in early data or carried `Early-Data: 1`.

The server wants the client to switch protocols before it will answer.

The server refuses the request over the current protocol but might accept it over another, and MUST send an Upgrade header naming what it wants. The RFC example asks a client to move to HTTP/3.0. A server can use it to insist on an encrypted or newer protocol version.

The server insists the request be conditional.

It exists to stop the lost-update problem, where two clients read a resource and the second write silently overwrites the first. The server refuses the unconditional write, and the response should explain how to resend it, typically by adding If-Match with the ETag you read. Responses with 428 must not be stored by a cache.

You have been rate limited.

The client sent too many requests in a given amount of time. The response should explain the limit and may include Retry-After saying how long to wait; back off for at least that long, ideally with jitter. The specification deliberately does not define how the server identifies a user or counts requests. Responses with 429 must not be stored by a cache.

The request headers are too big for the server to accept.

It covers both the headers as a whole and one oversized field, and in the latter case the response should name the field at fault. Enormous cookies are the usual cause. Trim the headers and resend. Responses with 431 must not be stored by a cache.

Access is blocked because of a legal demand.

The blocking server need not be the origin; the code was written with ISPs and search engines in mind. The response should explain the demand: who made it, under what law, and which people and resources it covers, and can carry a Link header with `rel="blocked-by"`. RFC 7725 adds that the code "implies neither the existence nor nonexistence of the resource named in the request", that a 451 response is cacheable by default, and closes its acknowledgements with "Thanks also to Ray Bradbury."

The server hit an unexpected condition and could not finish the request.

It is the generic server-side failure: an unhandled exception, a bad configuration, a crash in application code. It says nothing about the cause on purpose, so the answer is always in the server logs rather than the response. A retry may work if the failure was transient, but nothing about the code promises that.

The server does not support what the request needs at all.

RFC 9110 calls it the right answer when the server does not recognise the request method and could not support it for any resource. That is the difference from 405, which is about a method the server knows but this resource does not allow. It is heuristically cacheable.

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

The machine you reached is fine; the one it forwarded to answered with something unusable, or refused the connection. It is the classic sign of an application process that is down or crashing behind nginx, a load balancer or a CDN. Check the upstream service, not the proxy.

The server is temporarily unable to handle the request.

RFC 9110 gives temporary overload and scheduled maintenance as the causes, and says the condition will likely be over after some delay. The server may send Retry-After to say how long to wait, as a number of seconds or an HTTP date. The RFC notes that an overloaded server is not obliged to use 503; some simply refuse the connection.

A proxy or gateway waited for the server behind it and gave up.

The upstream server accepted the request but did not answer in time, so the difference from 502 is silence rather than a broken answer. Slow queries, exhausted worker pools and proxy timeouts set too low all produce it. Look at how long the upstream takes before raising the timeout.

The server refuses the major HTTP version the request used.

It is about the major version in the request message, not a minor feature the server lacks. The server should describe why that version is unsupported and which protocols it does speak. You are most likely to see it from a malformed request line that a server reads as an impossible version.

A content negotiation loop caused by a server misconfiguration.

In transparent content negotiation the chosen variant is itself configured to negotiate, so it is not a proper end point and the process cannot terminate. It is an internal configuration error, which is why it is a 5xx. Transparent content negotiation is experimental and rarely deployed.

The server has no room to store what the request would write.

A WebDAV server sends it when it cannot store the representation needed to complete the method, and the condition is considered temporary. If the request came from a user action, the client must not repeat it automatically; wait for the user to ask again. Some object stores and file APIs reuse it outside WebDAV.

The server stopped because a request kept going round in circles.

It appears in WebDAV when a `Depth: infinity` operation runs into an infinite loop of bindings, for example a collection bound inside itself. The status means the whole operation failed, not just one branch. It is also the fallback for clients that do not understand 208.

An obsolete code from the HTTP extension framework, saying the request lacked a required extension.

RFC 2774 defined it for a resource whose access policy was not met, with the response describing the extensions the client would have to declare. The experiment was moved to Historic status and the registry now lists the code as obsoleted. Nothing current should send it.

Registry note. Obsoleted. The registry lists the phrase as "Not Extended (OBSOLETED)".

You have to log in to the network itself, not to the site you asked for.

It is meant for captive portals, the hotel and airport Wi-Fi gateways that intercept traffic until you accept the terms. The response should link to the page where credentials can be submitted rather than embedding the login form, because a browser would otherwise attribute that form to the site you originally requested. Intercepting proxies that return 200 with a login page instead are the reason so many captive portals confuse clients.