BROWSER TOOLSOpen source

HTTP Status Code Reference Complete 1xx-5xx HTTP Status Directory

Interactive reference guide for 1xx, 2xx, 3xx, 4xx and 5xx HTTP response status codes with RFC definitions.

Back home
100Continue
RFC 9110 §15.2.1
Interim response indicating client should continue request or ignore if finished.
Used with Expect: 100-continue request header.
101Switching Protocols
RFC 9110 §15.2.2
Server agrees to switch protocols specified in Upgrade header (e.g. WebSocket).
Sent in response to an Upgrade request header from the client.
103Early Hints
RFC 8297
Allows server to return response headers before final HTTP message for preload optimization.
Mainly used for Link header preload hints.
200OK
RFC 9110 §15.3.1
Standard successful HTTP response for GET, POST, PUT, DELETE requests.
The payload contains the requested resource representation.
201Created
RFC 9110 §15.3.2
Request succeeded and a new resource was created.
Typically includes a Location header pointing to the new resource.
202Accepted
RFC 9110 §15.3.3
Request accepted for background asynchronous processing but not yet completed.
Useful for queue jobs and batch tasks.
204No Content
RFC 9110 §15.3.5
Request succeeded but response body is intentionally empty.
Commonly returned after DELETE or preflight OPTIONS requests.
301Moved Permanently
RFC 9110 §15.4.2
Resource permanently moved to a new URI given in Location header.
Search engines transfer SEO rank to the target URL.
302Found (Temporary Redirect)
RFC 9110 §15.4.3
Resource temporarily resides under a different URI.
Client should keep using the original URI for future requests.
304Not Modified
RFC 9110 §15.4.5
Resource unchanged since last fetch based on If-Modified-Since or If-None-Match headers.
Client should load representation from local browser cache.
307Temporary Redirect
RFC 9110 §15.4.8
Temporary redirect preserving original HTTP method and body.
Unlike 302, guarantees POST requests will not be converted to GET.
308Permanent Redirect
RFC 9110 §15.4.9
Permanent redirect preserving original HTTP method and body.
Guarantees POST method is preserved during permanent redirection.
400Bad Request
RFC 9110 §15.5.1
Server cannot process request due to malformed syntax or invalid payload.
Client must fix invalid body, parameters or headers before retrying.
401Unauthorized
RFC 9110 §15.5.2
Authentication is required and has failed or not been provided.
Response includes WWW-Authenticate header with auth scheme.
403Forbidden
RFC 9110 §15.5.4
Server understands request but refuses to authorize access regardless of credentials.
Indicates insufficient permissions (e.g. role-based access control).
404Not Found
RFC 9110 §15.5.5
Target resource does not exist on the server.
Can be returned to hide confidential resources from unauthorized users.
405Method Not Allowed
RFC 9110 §15.5.6
HTTP method used is not supported for target resource.
Response must include Allow header specifying valid methods (e.g. GET, POST).
409Conflict
RFC 9110 §15.5.10
Request conflicts with current state of server resource (e.g. duplicate key).
Common in version control conflicts or unique constraint violations.
429Too Many Requests
RFC 6585 §4
User sent too many requests in a given time window (Rate Limited).
Response often includes Retry-After header indicating wait duration.
500Internal Server Error
RFC 9110 §15.6.1
Server encountered an unexpected condition that prevented request completion.
Generic error code indicating unhandled server-side exceptions.
502Bad Gateway
RFC 9110 §15.6.3
Server acting as gateway/proxy received invalid response from upstream server.
Common with reverse proxies like Nginx or Cloudflare when app service fails.
503Service Unavailable
RFC 9110 §15.6.4
Server temporarily unable to handle request due to overload or maintenance.
Includes optional Retry-After header indicating backoff estimate.
504Gateway Timeout
RFC 9110 §15.6.5
Server acting as gateway did not receive timely response from upstream server.
Occurs when backend application takes longer to execute than proxy timeout.