Comprehensive documentation for all HTTP status codes with practical examples
Use interim responses to acknowledge progress before the final response is ready, especially for protocol negotiation or long-running request handling.
Use 100 as an interim response when a client asked whether it should continue sending the request body.
Use 101 when the client requested a protocol upgrade and the server is switching this connection to that protocol.
Use 102 as an interim WebDAV response when processing is underway and the final status is not ready yet.
Use success responses when the server accepted, completed, or can clearly confirm the request outcome and any resulting state.
Use 202 when the request is accepted but the real work will finish later, if it finishes at all.
Use 203 mainly from a transforming proxy when the origin's successful response was modified before delivery.
Use 205 when the request succeeded and the user agent should reset the document view that submitted it.
Use 206 when a valid Range request asks for one or more portions of a representation.
Use 207 mainly in WebDAV when one request needs to report separate statuses for multiple resources or properties.
Use 208 inside WebDAV multi-status results when a bound resource was already reported earlier in the same response.
Use redirection responses when the server needs the client to fetch somewhere else, reuse a cached result, or follow another request step.
Use 300 when more than one representation or target is valid and the client should pick the preferred one.
Use 301 for permanent redirects when moving the resource for good and method preservation is not the main concern.
Use 302 for temporary redirects when you are comfortable with traditional redirect behavior and the original URI should remain the one clients keep using.
Use 303 when the original request succeeded or was accepted, but the client should retrieve a different resource next with GET or HEAD.
Use 304 for conditional GET or HEAD requests when the client's cached representation is still current.
Use 307 when the redirect is temporary and the follow-up request must keep the same method and body.
Use client-error responses when the request is invalid, unauthorized, conflicts with resource rules, or needs the caller to change something.
Use 401 when authentication is missing, invalid, or expired and the client can authenticate.
Treat 402 as a nonstandard, reserved status that some products use for billing or subscription gates.
Use 403 when the request is understood but the client is not allowed to perform it, even with current authentication.
Use 404 when the server cannot find the target resource and is not making a stronger permanence claim.
Use 405 when the server knows the method but this specific resource does not support it.
Use 406 when the client's proactive negotiation constraints leave no representation you are willing to serve.
Use 407 when a proxy requires authentication before it will forward the request.
Use 408 when the server times out waiting for the client to send a complete request.
Use 409 when the request is valid but conflicts with the current resource or system state.
Use 410 when the resource used to exist and the server knows it has been removed permanently.
Use 411 when the server refuses to accept the request without a defined Content-Length.
Use 412 when the client supplied a conditional header and that precondition evaluated to false.
Use 413 when the request content is larger than the limits the server is willing or able to process.
Use 414 when the request target URI is longer than the server is willing to interpret.
Use 415 when the request content type or content coding is not supported for this resource or method.
Use 416 when a supported Range request is syntactically valid but unsatisfiable for the selected representation.
Use 421 when the request reached a server that cannot produce a response for that scheme-and-authority combination.
Use 422 when the request is well-formed and understood, but its instructions or values are semantically invalid.
Use 423 in WebDAV-style locking systems when the resource is currently locked and the request cannot proceed.
Use 424 in WebDAV-style multi-step operations when this action failed only because a dependent action failed first.
Use 425 when the server will not risk processing a replayable request sent in TLS early data.
Use 426 when the server refuses the current protocol but is willing to continue after the client upgrades.
Use 428 when the server requires the request to be conditional, usually to prevent lost updates.
Use 429 when a requester exceeds a rate limit or quota that applies to that client.
Use 431 when one header field or the total request header section is too large to process.
Use server-error responses when the request may be valid but the server or an upstream dependency could not complete it safely.
Use 500 when an unexpected server-side fault prevents the request from being fulfilled and no more specific 5xx status applies.
Use 501 when the server does not support the request method or required functionality anywhere on the server.
Use 502 when acting as a gateway or proxy and the upstream server sends an invalid or unusable response.
Use 503 when the service is temporarily unable to handle requests because of overload, maintenance, or another short-lived capacity issue.
Use 504 when acting as a gateway or proxy and the upstream server did not respond before your timeout expired.
Use 505 when the request's HTTP major version is unsupported or intentionally refused by the server.
Use 506 for a transparent content negotiation misconfiguration where the selected variant is itself negotiable and causes a loop or invalid resolution path.
Use 507 when the server cannot store the representation needed to complete the request because storage-related resources are exhausted.
Use 508 when a WebDAV operation fails because the server detected an infinite loop while traversing resources.
Use 510 when the request depends on a mandatory HTTP extension or extension declaration that the server cannot satisfy.