HTTP status codes

The server has received the request headers and the client may send the body. It's the answer to a request with Expect: 100-continue, which lets a client check whether a large upload will be accepted before sending it.

The server agrees to switch to the protocol the client asked for in the Upgrade header. The most common case is the handshake that opens a WebSocket connection.

A WebDAV code (RFC 2518) telling the client that the server is still working on a long-running request, so it shouldn't time out. It was dropped from the WebDAV spec in RFC 4918 and is rarely used today.

Sent before the final response with Link headers, so the browser can start preloading stylesheets or preconnecting to other origins while the server is still building the page (RFC 8297). Modern browsers and CDNs such as Cloudflare support it.

The request succeeded. For a GET the response body contains the requested resource; this is the code every normal, indexable page should return.

The request created a new resource, typically after a POST or PUT to an API. The Location header usually points to the new resource.

The request was accepted for processing, but processing hasn't finished yet and may still fail. Used for asynchronous jobs such as queued exports.

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

The request succeeded and there is intentionally no response body. Common for API calls such as DELETE or for saving a form without leaving the page.

The request succeeded and the client should reset the document view, for example clear the form that was just submitted. No body is sent.

The server returns only part of the resource because the client sent a Range header. Used for resuming downloads and seeking in video and audio files.

A WebDAV code (RFC 4918): the body is an XML document containing separate status codes for several resources or operations.

Used inside a WebDAV 207 response (RFC 5842) to avoid listing the same bound resource repeatedly.

The server returns the result of instance manipulations applied to the resource, such as a delta instead of the full document (RFC 3229). Hardly ever seen in practice.

The resource has several representations (for example different languages or formats) and the client or user should pick one. Browsers don't handle this consistently, so it's rarely used.

The resource has permanently moved to the URL in the Location header. Clients may change a POST into a GET when following it. The classic choice for domain moves, HTTPS migrations and changed URLs, see 301 vs. 302.

The resource is temporarily available at a different URL; clients should keep using the original URL. Like with 301, browsers usually switch POST to GET.

The client should fetch a different URL with GET. Typically sent after a form POST to send the user to a confirmation page (Post/Redirect/Get pattern), which prevents duplicate submissions on reload.

The answer to a conditional request with If-None-Match or If-Modified-Since: the resource hasn't changed, so the client can use its cached copy. The response has no body.

Deprecated. It told the client to access the resource through a proxy, which was a security risk, so browsers ignore it.

Formerly "Switch Proxy" in an early draft. The code is reserved and no longer used.

A temporary redirect like 302, but the client must repeat the request with the same method and body. Browsers also show an internal 307 when HSTS forces the switch from HTTP to HTTPS. Details in 307 vs. 308.

A permanent redirect like 301, but the method and body must not change, so a POST stays a POST. Well suited for APIs and form endpoints (originally defined in RFC 7538).

The server can't process the request because of a client error, such as malformed syntax, an invalid header or a cookie that is too large.

The request requires authentication and none or invalid credentials were sent. The server must include a WWW-Authenticate header describing how to authenticate.

Reserved for future use. Some APIs and services use it for exhausted quotas or unpaid accounts, but there is no standardised meaning.

The server understood the request but refuses to fulfil it. Unlike 401, logging in usually doesn't help, for example because of missing permissions, an IP block or a firewall rule.

The server can't find a resource at this URL. It doesn't say whether the absence is temporary or permanent. The most common error on the web, often caused by broken links or missing redirects after a relaunch.

The resource exists but doesn't support the request method, for example a POST to a static page. The response must include an Allow header listing the supported methods.

The server has no representation that matches the client's Accept headers (content type, language, encoding). Some security modules also misuse it to block requests.

Like 401, but the client has to authenticate with a proxy. The proxy sends a Proxy-Authenticate header.

The server didn't receive the complete request within the time it was willing to wait and closes the connection. The client may repeat the request.

The request conflicts with the current state of the resource, for example an edit based on an outdated version or an attempt to create something that already exists.

The resource was deliberately removed and won't come back, and there is no forwarding address. More explicit than 404 for content you have deleted on purpose.

The server refuses the request because it has no Content-Length header.

A condition in the request headers, such as If-Match or If-Unmodified-Since, evaluated to false. Used to prevent overwriting changes made by someone else.

The request body is larger than the server is willing to process, typically an upload that exceeds a limit like nginx's client_max_body_size. Formerly called "Payload Too Large".

The URL is longer than the server accepts. This often shows up with faulty redirect rules that append parameters on every hop until the URL becomes too long.

The server doesn't support the format of the request body, for example XML sent to an API that only accepts JSON. Check the Content-Type header.

The byte range in the Range header lies outside the resource, for example beyond the end of the file.

The server can't meet the requirement in the Expect header, usually Expect: 100-continue.

Known as "I'm a teapot" from the April Fools' RFC 2324 (Hyper Text Coffee Pot Control Protocol). RFC 9110 reserves the code because it is widely implemented as a joke, so it can't be assigned otherwise.

The request reached a server that can't produce a response for this host. Happens with HTTP/2 connection reuse when a TLS certificate covers several domains that are served by different servers.

The request is syntactically correct but semantically invalid, for example a JSON body that fails validation. Very common in REST APIs; formerly "Unprocessable Entity" from WebDAV.

A WebDAV code (RFC 4918): the resource is locked, for example because another user is editing it.

A WebDAV code (RFC 4918): the request failed because a previous request it depends on failed.

The server won't process a request sent as TLS 1.3 early data (0-RTT) because it could be replayed (RFC 8470). The client should retry after the handshake is complete.

The server refuses to handle the request with the current protocol and names the required one in the Upgrade header, for example a newer TLS or HTTP version.

The server requires a conditional request such as If-Match to prevent lost updates (RFC 6585).

The client sent too many requests in a given time (rate limiting, RFC 6585). A Retry-After header can say how long to wait before trying again.

A single header or all headers together are too large (RFC 6585). A frequent cause is too many or oversized cookies; deleting cookies for the domain usually fixes it.

The resource can't be served for legal reasons, for example because of a court order or geoblocking required by law (RFC 7725). The number is a reference to Ray Bradbury's "Fahrenheit 451".

A generic error: something went wrong on the server and no more specific code fits. Typical causes are PHP fatal errors, invalid .htaccess directives or failing database connections. The server's error log tells you more.

The server doesn't support the functionality required for the request, typically an unknown request method.

A gateway or reverse proxy (for example nginx or a CDN) received an invalid response from the upstream server, such as a crashed PHP-FPM or Node.js process.

The server is temporarily unable to handle the request, because of overload or maintenance. A Retry-After header can say when to try again. The correct code for planned maintenance windows.

A gateway or proxy didn't get a response from the upstream server in time, for example because a script runs longer than the proxy timeout.

The server doesn't support the major HTTP version used in the request.

A configuration error in transparent content negotiation (RFC 2295): the chosen variant is itself set up to negotiate, creating a loop.

A WebDAV code (RFC 4918): the server can't store the data needed to complete the request, for example because the disk or quota is full.

A WebDAV code (RFC 5842): the server detected an infinite loop while processing the request. Some hosts also use it when an account exceeds its resource limits.

The request needs further extensions for the server to fulfil it (RFC 2774). The underlying extension framework is historic and the code is practically unused.

The client must authenticate to get network access (RFC 6585). Sent by captive portals in hotel or airport Wi-Fi, not by the website you're trying to reach.