HTTP Status Code Reference
Complete reference of all HTTP status codes organized by category. Search by code number, name, or description to find exactly what you need.
Continue
The server has received the request headers and the client should proceed to send the request body.
Switching Protocols
The server is changing protocols as requested by the client, typically for WebSocket upgrades.
Processing
The server is still processing the request and has not completed it yet. Used to prevent client timeouts.
Early Hints
Used to return preliminary response headers before the final HTTP message is ready, improving page load performance.
OK
The request succeeded. The response body contains the requested resource or operation result.
Created
The request succeeded and a new resource was created as a result. Common response for POST and PUT requests in REST APIs.
Accepted
The request has been accepted for processing but is not yet complete. Used for async operations like batch jobs.
Non-Authoritative Information
The response was received from a third-party source rather than the origin server, such as a proxy or CDN.
No Content
The request succeeded but there is no body to return. Commonly used after successful DELETE operations.
Reset Content
The client should reset the document view that sent the request. Often used after form submissions.
Partial Content
The server returned only a portion of the resource as requested by the Range header. Used for resumable downloads.
Multi-Status
The response contains multiple status codes for independent sub-operations. Used in WebDAV and batch APIs.
Already Reported
Members of a DAV binding have already been enumerated in a previous response and are not repeated.
IM Used
The server has fulfilled a GET request and the response represents one or more instance manipulations applied to the instance.
Multiple Choices
The request has multiple possible responses. The client should choose one return option.
Moved Permanently
The requested resource has been permanently moved to a new URL. Search engines update their index to the new location.
Found
The resource is temporarily located at a different URL. The client should continue using the original URL for future requests.
See Other
The server redirects to a different resource, typically after a POST request, to prevent duplicate submissions.
Not Modified
The resource has not been modified since the version specified by the request headers. The client can use its cached version.
Use Proxy
The requested resource must be accessed through the proxy specified in the Location header. Deprecated for security.
Temporary Redirect
The resource is temporarily at a different URL but the HTTP method must not change. Unlike 302, preserves the original method.
Permanent Redirect
The resource has been permanently moved and the HTTP method must not change. Unlike 301, preserves POST data.
Bad Request
The server cannot process the request due to malformed syntax, invalid parameters, or a corrupted request body.
Unauthorized
Authentication is required and has either not been provided or has failed. The client should retry with valid credentials.
Payment Required
Reserved for future use in digital payment systems. Currently non-standard but may be used for subscription-based APIs.
Forbidden
The server understands the request but refuses to authorize it. Unlike 401, re-authenticating will not help.
Not Found
The requested resource does not exist on the server. The server may return this even when the path is valid but the record is missing.
Method Not Allowed
The HTTP method used is not supported for this resource. The response should include an Allow header listing valid methods.
Not Acceptable
The server cannot produce a response matching the Accept headers sent by the client, typically due to content negotiation.
Proxy Authentication Required
Similar to 401 but the client must authenticate with a proxy server before the request can proceed.
Request Timeout
The server timed out waiting for the client to complete the request. The client may retry the request.
Conflict
The request conflicts with the current state of the resource. Common in concurrent edit scenarios and versioning systems.
Gone
The resource is permanently deleted and no forwarding address is known. More explicit than 404 for SEO purposes.
Length Required
The server requires a Content-Length header and the client did not send one.
Precondition Failed
A request header precondition (If-Match, If-None-Match, If-Unmodified-Since) evaluated to false. Used for optimistic concurrency.
Payload Too Large
The request body exceeds the server's maximum allowed size. The client should reduce the payload or use chunked transfer.
URI Too Long
The requested URL is longer than the server can process. Usually triggered by overly long query strings or nested paths.
Unsupported Media Type
The server does not support the Content-Type of the request body. The client should use a supported media type.
Range Not Satisfiable
The byte range specified in the Range header cannot be satisfied. The response should include the valid content range.
Expectation Failed
The server cannot meet the requirements of the Expect request header, usually related to the 100-continue flow.
I'm a Teapot
The server refuses to brew coffee because it is a teapot. Originally an April Fools RFC (2324) that became a beloved developer meme.
Misdirected Request
The request was directed to a server that cannot produce a response, possibly due to connection reuse or SSL issues.
Unprocessable Entity
The server understands the request format but cannot process the contained instructions due to semantic errors like validation failures.
Locked
The resource being accessed is locked and cannot be modified. Used in WebDAV and collaborative editing systems.
Failed Dependency
The request failed because it depended on another request that also failed. Used in WebDAV multi-step operations.
Too Early
The server is unwilling to process a request that might be replayed. Used to prevent TLS 0-RTT replay attacks.
Upgrade Required
The server requires the client to upgrade to a different protocol, typically HTTPS or WebSocket.
Precondition Required
The server requires the request to be conditional to prevent the lost update problem in concurrent edits.
Too Many Requests
The client has sent too many requests in a given timeframe (rate limiting). The Retry-After header indicates when to try again.
Request Header Fields Too Large
The server refuses to process the request because one or more header fields are too large.
Unavailable For Legal Reasons
The server is denying access to the resource due to legal demands, censorship, or government takedown orders.
Internal Server Error
An unexpected condition was encountered by the server. This is a catch-all for unhandled exceptions and bugs.
Not Implemented
The server does not support the functionality required to fulfill the request. Used when a feature is planned but not yet built.
Bad Gateway
The server received an invalid response from an upstream server while acting as a gateway or proxy. Often caused by backend crashes.
Service Unavailable
The server is temporarily unable to handle requests due to maintenance, overload, or deployment. Retry-After header indicates when to retry.
Gateway Timeout
The server acting as a gateway did not receive a timely response from the upstream server. Common in microservice and CDN setups.
HTTP Version Not Supported
The server does not support the HTTP protocol version used in the request. Modern servers support HTTP/1.1 and HTTP/2.
Variant Also Negotiates
Transparent content negotiation for the request results in a circular reference. A server configuration error.
Insufficient Storage
The server cannot store the representation needed to complete the request. Used in WebDAV for disk-full scenarios.
Loop Detected
The server detected an infinite loop while processing the request. Used in WebDAV to prevent infinite redirect chains.
Not Extended
Further extensions to the request are required for the server to fulfill it. The client must declare mandatory extensions.
Network Authentication Required
The client must authenticate to gain network access, typically on captive portals for public WiFi networks.
Status codes are defined by RFC 9110 and its predecessors. This reference includes both standard codes and widely adopted non-standard extensions used by major platforms and frameworks.
HTTP status codes are the universal language of web communication — a concise, three-digit response that tells the client whether a request succeeded, failed, or needs further action. For developers building APIs, debugging network issues, or implementing error handling, understanding what each code means and when to use it is essential knowledge. Our HTTP Status Code Reference is a complete, searchable cheat sheet covering all standard 1xx through 5xx codes with detailed descriptions and real-world scenarios. Use the quick links to jump to a category, search by code number or keyword, and keep this page bookmarked for your next API implementation, incident response, or RFC deep dive.
Understanding HTTP Status Code Classes
HTTP status codes are grouped into five classes based on the first digit:
- 1xx Informational — The server received the request and is continuing to process it. These are
interim responses rarely seen by application code. The most notable is
100 Continue, used by clients to check if the server will accept a request body before sending it. - 3xx Redirection — The client must take additional action to complete the request, typically
following a different URL. Permanent (301, 308) vs temporary (302, 307)
redirects have significant SEO implications. The
304 Not Modifiedcode powers browser caching by telling clients to reuse their cached version. - 4xx Client Error — The client appears to have made an error — bad syntax, missing authentication,
permission denied, or the resource doesn't exist. The
404 Not Foundis the most recognized HTTP status code among non-developers, while429 Too Many Requestsis increasingly critical for API rate limiting. - 5xx Server Error — The server failed to fulfill a valid request. These indicate problems on the
server side and are the codes you hope your monitoring alerts on. The
500 Internal Server Erroris the catch-all, while502/503/504are the holy trinity of downtime debugging in proxy and microservice architectures.
When to Use This Reference
- API Design: Choose the semantically correct status code for each endpoint response. Don't
return
200 OKwith an error message in the body — use 4xx codes to signal client issues. - Debugging: When your frontend or API client receives an unexpected status code, search this reference to understand exactly what the server is communicating.
- Interview Preparation: Knowing HTTP status codes — especially the difference between 401/403, 301/302/307/308, and 502/503/504 — is a staple of backend and full-stack developer interviews.
- Error Handling: Implement proper retry logic based on status codes: retry on 429 with backoff, never retry on 4xx (except 408/429), retry on 5xx with circuit breaker patterns.