HTTP Status Code Reference

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

Use case: Large file uploads where the server checks headers before accepting the body.

The server is switching protocols as requested by the client.

Use case: Upgrading from HTTP to WebSocket connections.

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

Use case: Long-running WebDAV operations.

Used to return some response headers before the final HTTP message.

Use case: Preloading resources while the server prepares the full response.

The request has succeeded.

Use case: Standard response for successful GET, POST, PUT requests.

The request has succeeded and a new resource has been created.

Use case: Successful POST request that creates a new record.

The request has been accepted for processing, but the processing is not complete.

Use case: Queued background jobs or async operations.

The returned metadata is not exactly the same as from the origin server.

Use case: Proxy or cache returning modified headers.

The server successfully processed the request but returns no content.

Use case: Successful DELETE requests or form submissions with no redirect.

The server successfully processed the request and asks the client to reset the document view.

Use case: Form submission where the browser should clear the form.

The server is delivering only part of the resource due to a range header.

Use case: Video streaming, resumable downloads.

A multi-status response conveys information about multiple resources.

Use case: WebDAV batch operations with mixed results.

The request has more than one possible response.

Use case: Content negotiation with multiple formats available.

The URL of the requested resource has been changed permanently.

Use case: SEO-friendly permanent URL redirects.

The URI of the requested resource has been changed temporarily.

Use case: Temporary redirects during maintenance.

The server directs the client to get the resource at another URI with a GET request.

Use case: Redirect after a POST form submission (POST/Redirect/GET pattern).

The resource has not been modified since the last request.

Use case: Browser caching with ETag or If-Modified-Since headers.

The request should be repeated with another URI, but the method must not change.

Use case: Temporary redirect that preserves the HTTP method.

The request and future requests should use another URI, method must not change.

Use case: Permanent redirect that preserves the HTTP method.

The server cannot process the request due to a client error.

Use case: Malformed request syntax, invalid JSON body, missing required fields.

Authentication is required and has failed or has not been provided.

Use case: Missing or invalid authentication token.

The server understood the request but refuses to authorize it.

Use case: User authenticated but lacks permission to access the resource.

The server cannot find the requested resource.

Use case: Requested URL or resource does not exist.

The HTTP method is not allowed for the requested resource.

Use case: Sending POST to a read-only endpoint that only accepts GET.

The server cannot produce a response matching the Accept headers.

Use case: Client requests XML but server only produces JSON.

Authentication with the proxy is required.

Use case: Corporate proxy requiring login credentials.

The server timed out waiting for the request.

Use case: Client took too long to send the complete request.

The request conflicts with the current state of the server.

Use case: Duplicate resource creation, edit conflicts.

The resource is no longer available and will not be available again.

Use case: Permanently deleted content, deprecated API endpoints.

The server requires a Content-Length header.

Use case: Upload endpoints that need to know the size in advance.

The server does not meet one of the preconditions in the request headers.

Use case: Conditional requests using If-Match or If-Unmodified-Since.

The request entity is larger than the server is willing to process.

Use case: File upload exceeding the server's size limit.

The URI requested by the client is longer than the server is willing to interpret.

Use case: Extremely long query strings.

The media format of the requested data is not supported.

Use case: Sending XML to an endpoint that only accepts JSON.

The request is well-formed but semantically invalid.

Use case: Validation errors (e.g., email format wrong, date in past).

The user has sent too many requests in a given time.

Use case: API rate limiting.

The resource is unavailable due to legal demands.

Use case: Content blocked by court order or government censorship.

The server encountered an unexpected condition.

Use case: Unhandled exceptions, database errors, server bugs.

The server does not support the functionality required to fulfill the request.

Use case: Server doesn't support the HTTP method used.

The server received an invalid response from an upstream server.

Use case: Reverse proxy getting an error from the application server.

The server is not ready to handle the request.

Use case: Server maintenance, overloaded servers, deployment in progress.

The server acting as a gateway did not get a timely response.

Use case: Upstream server took too long to respond.

The HTTP version used in the request is not supported.

Use case: Server doesn't support HTTP/2 or the version requested.

The server cannot store the representation needed to complete the request.

Use case: WebDAV server running out of disk space.

The server detected an infinite loop while processing the request.

Use case: WebDAV infinite redirect loops.

The client needs to authenticate to gain network access.

Use case: Captive portals (hotel/airport Wi-Fi login pages).