HTTP Status Codes

The server has received the request headers and the client should proceed to send the request body.

The server is switching protocols as requested by the client (e.g., upgrading to WebSocket).

The server has received and is processing the request, but no response is available yet (WebDAV).

Used to return some response headers before the final HTTP message, allowing the browser to preload resources.

The request succeeded. The meaning 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 used as a response to POST requests.

The request has been accepted for processing, but the processing has not been completed. Used for async operations.

The server successfully processed the request but returns no content. Common response for DELETE operations.

The server is delivering only part of the resource due to a Range header sent by the client.

A multi-status response conveys information about multiple resources where multiple status codes might be appropriate (WebDAV).

The resource has been permanently moved to a new URL. Search engines will update their links. Use for permanent URL changes.

The resource temporarily resides at a different URL. The client should continue to use the original URL for future requests.

The response can be found at another URL using a GET request. Often used after POST to redirect to a confirmation page.

The resource has not been modified since the last request. Used for caching — the client can use its cached version.

The resource temporarily resides at a different URL. Unlike 302, the request method must not change (POST stays POST).

The resource has been permanently moved. Unlike 301, the request method must not change (POST stays POST).

The server cannot process the request due to malformed syntax, invalid parameters, or missing required fields.

Authentication is required. The client must provide valid credentials (API key, token, or login) to access this resource.

The server understood the request but refuses to authorize it. Authentication won't help — the user lacks permission.

The requested resource could not be found on the server. The URL may be incorrect or the resource may have been deleted.

The HTTP method used is not supported for this resource. For example, using POST on a read-only endpoint.

The server timed out waiting for the request. The client took too long to send the complete request.

The request conflicts with the current state of the server. Common in version control or when trying to create a duplicate resource.

The resource is no longer available and will not be available again. Unlike 404, this is a permanent condition.

The request body is larger than the server is willing to accept. Common for file upload limits.

The media type of the request body is not supported. For example, sending XML when only JSON is accepted.

The server refuses to brew coffee because it is, permanently, a teapot. An April Fools' joke from RFC 2324 that became a real HTTP status code.

The server understands the content but cannot process it. Used for validation errors — the syntax is correct but the data is invalid.

The user has sent too many requests in a given time period (rate limiting). Check the Retry-After header for when to retry.

The server encountered an unexpected condition that prevented it from fulfilling the request. A generic server-side error.

The server does not support the functionality required to fulfill the request. The method may not be recognized.

The server, acting as a gateway or proxy, received an invalid response from an upstream server.

The server is temporarily unable to handle the request due to maintenance or overloading. Usually temporary.

The server, acting as a gateway or proxy, did not receive a timely response from an upstream server.