HTTP Status Codes

The initial part of the request has been received and not rejected, so the client should carry on and send the rest.

When you see it: Sent in reply to a request with Expect: 100-continue, so a client can check that the headers are acceptable before uploading a large body.

Defined in RFC 9110, Section 15.2.1

The server agrees to switch this connection to the protocol named in the request's Upgrade header.

When you see it: Seen when a WebSocket handshake succeeds or a connection is upgraded to another protocol.

Defined in RFC 9110, Section 15.2.2

An interim WebDAV response saying the server has received the request and is still working on it, with no final response yet.

When you see it: Meant to stop clients timing out on slow WebDAV operations. It was dropped from RFC 4918, so new code should not rely on it.

Defined in RFC 2518

An interim response that lets the server send Link headers before the final response, so the client can start preloading resources.

When you see it: Used by servers and CDNs to hint at stylesheets or scripts to preload while the main response is still being prepared.

Defined in RFC 8297

The request succeeded. What the response carries depends on the method: a representation for GET, the result of the action for POST.

When you see it: The default success response for most requests.

Defined in RFC 9110, Section 15.3.1

The request succeeded and created one or more new resources. The new resource is usually identified by a Location header.

When you see it: The usual reply to a POST or PUT that creates a record in a REST API.

Defined in RFC 9110, Section 15.3.2

The request has been accepted for processing, but the processing has not finished and may still fail.

When you see it: Used for queued or asynchronous work, such as a background job whose result is available later.

Defined in RFC 9110, Section 15.3.3

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

When you see it: Rare. A proxy may send it when it rewrites or injects content on the way through.

Defined in RFC 9110, Section 15.3.4

The server handled the request successfully and has no content to send in the response body.

When you see it: The usual reply to a DELETE, or to a PUT or PATCH with nothing to return. Also common for CORS preflight responses.

Defined in RFC 9110, Section 15.3.5

The request succeeded and the client should reset the view that sent it, such as clearing a form.

When you see it: Rarely used. Meant for data-entry pages that should be cleared ready for the next input.

Defined in RFC 9110, Section 15.3.6

The server is delivering only the part of the resource that the client asked for with a Range header.

When you see it: Used for resumable downloads and for seeking within video or audio.

Defined in RFC 9110, Section 15.3.7

A WebDAV response whose XML body carries separate status codes for several independent operations.

When you see it: Returned by WebDAV methods such as PROPFIND when a request touches several resources. Some batch APIs borrow it too.

Defined in RFC 4918, Section 11.1

A WebDAV status used inside a Multi-Status body to say the members of a binding were already listed earlier in the same response.

When you see it: Appears with the WebDAV bindings extension, to avoid listing the same resource twice when a request uses Depth: infinity.

Defined in RFC 5842

The server fulfilled a GET request and the response is the result of applying one or more instance manipulations to the current instance.

When you see it: Part of delta encoding in HTTP (the A-IM header), which is rarely deployed.

Defined in RFC 3229

The target resource has more than one representation and the client can choose between them.

When you see it: Rarely used in practice. A server may list the choices in the body and name a preferred one in a Location header.

Defined in RFC 9110, Section 15.4.1

The resource has a new permanent URI and future requests should use it. A client may change POST to GET when it follows the redirect.

When you see it: Used for permanent moves such as a changed URL or a switch to HTTPS, and search engines transfer ranking to the new address. Use 308 to keep the method.

Defined in RFC 9110, Section 15.4.2

The resource is temporarily at a different URI, given in the Location header. A client may change POST to GET when it follows the redirect.

When you see it: The common default for temporary redirects, such as sending a visitor to a login page. Use 307 to keep the method.

Defined in RFC 9110, Section 15.4.3

The server is redirecting the client to a different resource, to be fetched with GET, that may describe the result of the original request.

When you see it: Used after a POST to send the client to a result page (the Post/Redirect/Get pattern).

Defined in RFC 9110, Section 15.4.4

A conditional GET or HEAD found that the resource has not changed since the version the client already has, so no body is sent.

When you see it: Returned when If-None-Match or If-Modified-Since still matches, which lets a browser reuse its cached copy.

Defined in RFC 9110, Section 15.4.5

Defined in an earlier version of HTTP to tell the client to repeat the request through the proxy named in the Location header. Now deprecated.

When you see it: Deprecated, partly because of security concerns. Servers should not send it and clients should not act on it.

Defined in RFC 9110, Section 15.4.6

Defined in an earlier version of HTTP and no longer used, but the number stays reserved.

When you see it: You should never see it. It is listed so the gap between 305 and 307 is explained.

Defined in RFC 9110, Section 15.4.7

The resource is temporarily at another URI. Unlike 302, the client must repeat the request with the same method and body.

When you see it: Use it when a temporary redirect must not turn a POST into a GET. Browsers also report it for internal HSTS upgrades from http to https.

Defined in RFC 9110, Section 15.4.8

The resource has permanently moved to the URI in the Location header. Unlike 301, the client must repeat the request with the same method and body.

When you see it: Use it instead of 301 for permanent moves of endpoints that receive POST, PUT or DELETE.

Defined in RFC 9110, Section 15.4.9

The server cannot or will not process the request because of something it takes to be a client error, such as malformed syntax or invalid framing.

When you see it: Common causes: invalid JSON, missing or malformed parameters, an oversized cookie header or a failed validation.

Defined in RFC 9110, Section 15.5.1

The request lacks valid authentication credentials for the target resource. The response includes a WWW-Authenticate header saying how to authenticate.

When you see it: Common causes: a missing, expired or wrong token, API key or password. The client is not identified yet; compare 403.

Defined in RFC 9110, Section 15.5.2

Reserved for future use. It was meant for digital payment schemes but has no standard meaning.

When you see it: Some APIs use it for billing problems, such as an expired subscription or an exhausted paid quota.

Defined in RFC 9110, Section 15.5.3

The server understood the request but refuses to fulfil it. Sending different credentials may or may not help.

When you see it: Common causes: the signed-in user lacks permission, an IP or region block, or a failed CSRF check. Some servers answer 404 instead to hide that a resource exists.

Defined in RFC 9110, Section 15.5.4

The server did not find a current representation for the target resource, or does not want to say that one exists.

When you see it: Common causes: a mistyped URL, a deleted or moved page, or a wrong route or base path. It does not say whether the condition is permanent; 410 does.

Defined in RFC 9110, Section 15.5.5

The method in the request is known to the server but not supported by the target resource. The response includes an Allow header listing the methods that are.

When you see it: Common causes: a POST to a read-only endpoint, or no route handler for the method, such as DELETE.

Defined in RFC 9110, Section 15.5.6

The server cannot produce a response that matches the content negotiation headers in the request, such as Accept or Accept-Language.

When you see it: Common cause: an Accept header asking for a format the endpoint does not offer. Many servers ignore Accept and send a default instead.

Defined in RFC 9110, Section 15.5.7

Like 401, but the client must first authenticate with a proxy. The response includes a Proxy-Authenticate header.

When you see it: Seen behind corporate proxies when the proxy credentials are missing or wrong.

Defined in RFC 9110, Section 15.5.8

The server did not receive a complete request in the time it was prepared to wait, so it is closing the connection.

When you see it: Common causes: a stalled upload, an idle keep-alive connection or a flaky network. The client may repeat the request on a new connection.

Defined in RFC 9110, Section 15.5.9

The request conflicts with the current state of the target resource, so the server cannot complete it.

When you see it: Typical for edit conflicts, a duplicate of a unique value such as an existing username, or a version mismatch on update.

Defined in RFC 9110, Section 15.5.10

The target resource is no longer available at the origin server and this condition is likely to be permanent.

When you see it: Use it instead of 404 when a page was removed on purpose, so clients and crawlers can drop the URL.

Defined in RFC 9110, Section 15.5.11

The server refuses to accept the request without a defined Content-Length.

When you see it: Seen when a client sends a body without a length, for example with chunked encoding, to a server that needs it up front.

Defined in RFC 9110, Section 15.5.12

One or more conditions in the request headers, such as If-Match or If-Unmodified-Since, evaluated to false on the server.

When you see it: Used for optimistic concurrency: an update that carries a stale ETag in If-Match is rejected.

Defined in RFC 9110, Section 15.5.13

The request content is larger than the server is willing or able to process. Formerly named Payload Too Large and Request Entity Too Large.

When you see it: Common cause: a file upload over a size limit set in the web server, proxy or framework, such as nginx client_max_body_size.

Defined in RFC 9110, Section 15.5.14

The request target is longer than the server is willing to interpret.

When you see it: Common causes: a very long query string, a form that should have been a POST, or a redirect loop that keeps growing the URL.

Defined in RFC 9110, Section 15.5.15

The server refuses the request because its content format or content encoding is not supported by the target resource for this method.

When you see it: Common cause: a wrong or missing Content-Type, such as form data sent to an endpoint that expects application/json.

Defined in RFC 9110, Section 15.5.16

None of the ranges in the request's Range header overlap the current extent of the resource, or the ranges were invalid.

When you see it: Seen when a download is resumed past the end of a file that has since changed. The response carries a Content-Range header with the real size.

Defined in RFC 9110, Section 15.5.17

The expectation in the request's Expect header could not be met by the server or by an intermediary.

When you see it: Rare. Mostly comes from servers or proxies that do not support Expect: 100-continue.

Defined in RFC 9110, Section 15.5.18

A joke code from the April Fools' Hyper Text Coffee Pot Control Protocol: a teapot refuses to brew coffee. RFC 9110 keeps the number reserved.

When you see it: Not for real errors. Servers return it as an Easter egg or to turn away unwanted requests, and it is reserved so nothing else can claim it.

Defined in RFC 2324 (reserved by RFC 9110, Section 15.5.19)

The request was sent to a server that cannot produce a response for the combination of scheme and authority in the request URI.

When you see it: Seen when an HTTP/2 connection is reused for a host the server is not set up to answer. The client can retry on a new connection.

Defined in RFC 9110, Section 15.5.20

The server understands the content type and syntax of the request but cannot process the instructions it contains. Formerly named Unprocessable Entity.

When you see it: Widely used by APIs for validation errors, such as a well-formed JSON body with invalid field values.

Defined in RFC 9110, Section 15.5.21

A WebDAV status: the source or destination resource of the method is locked.

When you see it: Seen when changing a WebDAV resource that another user or process has locked.

Defined in RFC 4918, Section 11.3

A WebDAV status: the method could not be performed because it depended on another action that failed.

When you see it: Appears in Multi-Status responses for an operation that was skipped because an earlier one failed.

Defined in RFC 4918, Section 11.4

The server is unwilling to risk processing a request that might be replayed, such as one sent in TLS 1.3 early data.

When you see it: Sent by servers that accept TLS 1.3 0-RTT data. The client should retry once the handshake has completed.

Defined in RFC 8470

The server refuses to perform the request using the current protocol but will do so after the client upgrades to a different protocol.

When you see it: The response carries an Upgrade header naming the acceptable protocols, for example when a server insists on a newer protocol version.

Defined in RFC 9110, Section 15.5.22

The origin server requires the request to be conditional.

When you see it: Used to prevent lost updates: the client must send If-Match so it cannot overwrite changes made by someone else.

Defined in RFC 6585, Section 3

The user has sent too many requests in a given amount of time, which is how rate limiting is reported.

When you see it: Common cause: going over an API rate limit. A Retry-After header may say how long to wait, so back off before retrying.

Defined in RFC 6585, Section 4

The server is unwilling to process the request because its header fields are too large, either all together or a single one.

When you see it: Common causes: bloated cookies or a very long header value such as a huge token. Clearing cookies often fixes it.

Defined in RFC 6585, Section 5

The server is denying access to the resource as a consequence of a legal demand.

When you see it: Used for content blocked by court orders or government demands. The number is a nod to the novel Fahrenheit 451.

Defined in RFC 7725

The server hit an unexpected condition that stopped it from fulfilling the request.

When you see it: The generic server-side failure: an unhandled exception, a bug, a misconfiguration or a failed dependency. Check the server logs.

Defined in RFC 9110, Section 15.6.1

The server does not support the functionality needed to fulfil the request, such as a request method it does not recognise.

When you see it: Means the server does not know the method at all. Compare 405, where the method is known but not allowed for this resource.

Defined in RFC 9110, Section 15.6.2

The server, acting as a gateway or proxy, received an invalid response from an inbound server while trying to fulfil the request.

When you see it: Common causes: the upstream app crashed, is restarting or sent a malformed reply to a reverse proxy or load balancer such as nginx.

Defined in RFC 9110, Section 15.6.3

The server is currently unable to handle the request because of temporary overload or scheduled maintenance, and will likely recover after some delay.

When you see it: Common during deployments, maintenance and traffic spikes. A Retry-After header may say when to try again.

Defined in RFC 9110, Section 15.6.4

The server, acting as a gateway or proxy, did not get a timely response from an upstream server it needed to reach.

When you see it: Common causes: a slow upstream service or database, or a proxy timeout that is shorter than the operation. Compare 408, which is about the client.

Defined in RFC 9110, Section 15.6.5

The server does not support, or refuses to support, the major HTTP version used in the request.

When you see it: Rare. Can happen when the request line carries a version the server does not accept.

Defined in RFC 9110, Section 15.6.6

A transparent content negotiation error: the chosen variant is itself set up to negotiate, so it is not a proper endpoint.

When you see it: Very rare. It points to a server misconfiguration in transparent content negotiation.

Defined in RFC 2295

A WebDAV status: the server cannot store the representation it needs to complete the request. The condition is considered temporary.

When you see it: Seen when a WebDAV server runs out of disk space or the user runs out of quota.

Defined in RFC 4918, Section 11.5

A WebDAV status: the server ended an operation because it found an infinite loop while processing a request with 'Depth: infinity'.

When you see it: Appears with the WebDAV bindings extension when bindings form a cycle.

Defined in RFC 5842

The request did not meet the policy of the HTTP Extension Framework, so the server needs further extensions. The code is now obsolete.

When you see it: Obsolete: RFC 2774 was moved to Historic status. You should not see it in current software.

Defined in RFC 2774

The client needs to authenticate to gain network access.

When you see it: Sent by intercepting proxies such as the captive portal on public Wi-Fi, which require a login before allowing internet access.

Defined in RFC 6585, Section 6