Complete HTTP status codes reference with search, filtering, and detailed descriptions. All 1xx–5xx codes with RFC specs, real-world examples, and developer-focused explanations.
The HTTP Status Codes Reference is an interactive, lightning-fast developer tool for exploring and understanding web server response codes. Designed for frontend engineers, backend developers, and SEO specialists, it provides immediate, offline-capable access to detailed explanations, common usage scenarios, and official specification links for over 60 HTTP status codes. Because it operates entirely locally in your browser, lookups are instantaneous. Whether you are debugging an elusive API error, configuring server redirects, or optimizing SEO crawlers, this tool delivers the technical clarity you need without the latency of a web search.
This reference tool is built as a static application using Astro and Vanilla JavaScript. The entire database of HTTP status codes is bundled into the client-side code. When you search or filter, a local JavaScript function instantly queries the dataset in memory and updates the DOM, ensuring zero network requests and sub-millisecond response times.
1. Quickly identifying the appropriate 4xx or 5xx error code to return when building RESTful API endpoints.
2. Understanding the difference between 301 and 302 redirects to ensure correct SEO implementation during site migrations.
3. Troubleshooting unexpected API responses in frontend applications by looking up obscure server codes.
Essential terms and definitions related to HTTP Status Codes Reference.
A three-digit integer returned in the first line of an HTTP response. The first digit indicates the response class (1xx–5xx), and the remaining digits provide specific meaning within that class. Status codes are defined by IETF RFCs and are the primary mechanism for communicating request outcomes between servers and clients.
A publication from the IETF (Internet Engineering Task Force) that defines internet standards and protocols. HTTP status codes are primarily defined in RFC 9110 (HTTP Semantics). RFCs go through a rigorous review process and serve as the authoritative specification for internet protocols.
An HTTP method is idempotent if making the same request multiple times produces the same result as making it once. GET, PUT, DELETE, and HEAD are idempotent. POST is not idempotent. Understanding idempotency is essential for choosing the correct status codes — for example, a duplicate POST should return 409 Conflict, while a duplicate PUT should return 200 OK.
HTTP status codes are three-digit numbers returned by web servers in response to client requests. They indicate whether a request succeeded (2xx), was redirected (3xx), failed due to a client error (4xx), or failed due to a server error (5xx). The first digit defines the category, and the remaining digits identify the specific condition.
401 Unauthorized means the request lacks valid authentication credentials — the user needs to log in or provide a valid API key. 403 Forbidden means the server understood the request and the user is authenticated, but they do not have permission to access the resource. Authentication will not help with a 403.
Return 404 Not Found when a resource does not exist or its existence is uncertain. Return 410 Gone when you know the resource existed previously but has been intentionally and permanently removed. 410 tells search engines to de-index the URL, while 404 leaves the possibility of return.
HTTP 429 Too Many Requests means the client has exceeded the rate limit imposed by the server. The response typically includes a Retry-After header indicating how long to wait before retrying. Implement exponential backoff in your client code to handle this gracefully.
Both indicate permanent redirects, but 301 allows the browser to change the HTTP method (e.g., POST to GET), while 308 preserves the original HTTP method. Use 301 for standard URL changes (HTTP to HTTPS, domain migration). Use 308 when you need to ensure POST requests remain POST after the redirect.
This reference includes all standard HTTP status codes from RFC 9110 (HTTP Semantics, 2022) which consolidated and replaced the older RFC 7231. It also includes extension codes from WebDAV (RFC 4918), rate limiting (RFC 6585), and other commonly used specifications.
Common errors developers encounter and how to resolve them.
Getting 502 Bad Gateway after deploying a new backend version 502 means the reverse proxy (Nginx, Apache, load balancer) received an invalid response from your application server. Common causes: application crashed during startup, wrong port configuration, application not listening on the expected address, or firewall blocking the connection. Check your application logs first, then verify the proxy upstream configuration.
API returns 200 OK but the response body contains an error Some APIs wrap errors inside a 200 response with an error field in the JSON body instead of using proper HTTP status codes. While this is considered a bad practice, it is common in older APIs. Always check both the HTTP status code and the response body for errors when integrating with external APIs.