The server has received the request headers and the client should proceed to send the request body. Used with large payloads where the client sends an Expect: 100-continue header first.
The server agrees to switch protocols as requested by the client. Commonly used when upgrading an HTTP connection to a WebSocket connection.
The server has received and is processing the request, but no response is available yet. Prevents the client from timing out on long-running operations.
Used to return response headers before the final HTTP message. Allows the browser to start preloading resources while the server prepares the full response.
The request succeeded. The meaning of the response depends on the HTTP method: GET returns the resource, POST returns the result of the action.
The request succeeded and a new resource was created. Typically returned after a POST or PUT request. The Location header often points to the new resource.
The request has been accepted for processing, but the processing has not been completed. Used for asynchronous operations where the result will be available later.
The returned metadata is not exactly the same as available from the origin server. Returned by a proxy that modified the response.
The request succeeded but there is no content to return. Common for DELETE requests and PUT/PATCH responses where the client already has the updated data.
The server successfully processed the request and asks the client to reset the document view. Used to clear a form after submission.
The server is delivering only part of the resource due to a range header sent by the client. Used for resumable downloads and video streaming.
Provides status for multiple independent operations. Common in WebDAV responses where a single request affects multiple resources with different outcomes.
The server fulfilled a GET request for the resource and the response is a representation of the result of one or more instance-manipulations applied to the current instance.
The request has more than one possible response. The user-agent or user should choose one of them. Used when content negotiation finds multiple valid options.
The URL of the requested resource has been changed permanently. The new URL is given in the Location header. Search engines update their links to the resource.
The URI of requested resource has been changed temporarily. The client should use the original URI for future requests. Often used after form submissions.
The response can be found under a different URI using the GET method. Used to redirect after a POST request to prevent duplicate submissions on refresh.
The client's cached version is still valid and no new content needs to be sent. Returned when conditional request headers indicate the cache is fresh.
The request should be repeated with another URI, but future requests should still use the original URI. Unlike 302, the HTTP method must not change.
The resource is now permanently located at another URI. Unlike 301, the HTTP method must not change. Use this when permanently moving an API endpoint.
The server cannot process the request due to client-side syntax errors, invalid parameters, or malformed request body. The client should fix the request before retrying.
Authentication is required and has failed or has not yet been provided. Despite the name, it's about authentication not authorization. The client must send valid credentials.
Reserved for future use, but commonly used by APIs to indicate the user needs to pay or upgrade their plan. Not standardized but widely adopted.
The server understood the request but refuses to authorize it. The client's identity is known but they lack the required permissions. Different from 401.
The server cannot find the requested resource. The URL is valid but the resource does not exist — it may have been deleted, moved, or never existed.
The HTTP method used is not supported for the requested resource. For example, sending a DELETE request to a read-only endpoint. The Allow header lists valid methods.
The server cannot produce a response that matches the list of acceptable values defined in the request's Accept headers. Used during content negotiation.
The client must first authenticate itself with the proxy server before the request can be forwarded. Similar to 401 but for proxy servers.
The server timed out waiting for the request. The client did not produce a request within the time the server was prepared to wait. The connection may be reused.
The request conflicts with the current state of the target resource. Common when trying to create a resource that already exists or when concurrent updates conflict.
The target resource is no longer available and will not be available again. Unlike 404, the resource used to exist but has been intentionally removed.
The server refuses to accept the request without a defined Content-Length header. The client must send the size of the request body.
One or more conditions in the request headers evaluated to false when tested on the server. Used with conditional requests for optimistic concurrency control.
The request entity is larger than limits defined by the server. Commonly triggered by large file uploads. The server may return a Retry-After header.
The URI requested by the client is longer than the server is willing to interpret. Usually caused by encoding too much data into a GET query string.
The media format of the requested data is not supported by the server. Often occurs when the Content-Type header doesn't match what the endpoint expects.
The range specified in the Range header cannot be fulfilled. The range is outside the bounds of the resource.
The expectation indicated in the Expect request-header field could not be met by the server. Commonly returned when the server doesn't support Expect: 100-continue.
Any attempt to brew coffee with a teapot should result in this error code. An April Fools' joke from RFC 2324 (1998). Sometimes used as an easter egg or to reject invalid requests.
The request was directed at a server that is not able to produce a response for the requested URI. Can occur with HTTP/2 connection reuse.
The server understands the content type and the syntax is correct, but it was unable to process the contained instructions due to semantic errors. Used for bean validation failures.
The resource that is being accessed is locked. Used in WebDAV to prevent concurrent modifications when a resource is checked out for editing.
The method could not be performed on the resource because the requested action depended on another action and that action failed.
The server is unwilling to risk processing a request that might be replayed. Used with TLS 1.3 Early Data (0-RTT) to prevent replay attacks.
The server refuses to perform the request using the current protocol but will accept it after the client upgrades. The Upgrade header specifies the required protocol.
The origin server requires the request to be conditional to prevent the "lost update" problem. The client must include conditional headers like If-Match.
The user has sent too many requests in a given amount of time. The response may include a Retry-After header. Common in APIs with rate limiting.
The server refuses to process the request because the request's HTTP headers are too large. Can occur with very large cookies or many custom headers.
The server is denying access to the resource as a consequence of a legal demand. Named after the Ray Bradbury novel Fahrenheit 451.
A generic error indicating an unexpected condition was encountered and no more specific message is suitable. Usually indicates a bug, uncaught exception, or misconfiguration on the server.
The server does not support the functionality required to fulfill the request. Used when the server does not recognize the HTTP method or lacks the ability to fulfill the request.
The server, while acting as a gateway or proxy, received an invalid response from an inbound server. Commonly seen when Nginx or an API Gateway cannot reach the upstream service.
The server is not ready to handle the request. Common causes are the server being down for maintenance or being overloaded. A Retry-After header may indicate recovery time.
The server, while acting as a gateway or proxy, did not get a response in time from an upstream server. Different from 408 — this is the proxy timing out.
The HTTP version used in the request is not supported by the server. Rarely seen in practice as most servers support HTTP/1.1 and HTTP/2.
The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself.
The method could not be performed because the server is unable to store the representation needed to complete the request. Used in WebDAV when disk space is full.
The server detected an infinite loop while processing the request. Used in WebDAV when processing a request with Depth: infinity causes a circular reference.
Further extensions to the request are required for the server to fulfil it. The server should send back the required extensions in the response body.
The client needs to authenticate to gain network access. Used by captive portals (hotel Wi-Fi, airport logins) to intercept requests and redirect to a login page.