Utility Tool

HTTP Status Code Reference

A complete reference guide for all HTTP status codes with descriptions and practical tips.

31 status codes found

1001xx

Continue

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

Tip: Used when the client sends a large body and wants to check if the server will accept it before sending.

1011xx

Switching Protocols

The server is switching protocols as requested by the client via the Upgrade header.

Tip: Commonly used when upgrading from HTTP to WebSocket connections.

1021xx

Processing

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

Tip: Used for long-running operations to prevent client timeout.

2002xx

OK

The request has succeeded. The meaning of the success depends on the HTTP method used.

Tip: This is the standard response for successful HTTP requests.

2012xx

Created

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

Tip: Typically returned after a POST request that creates a new record.

2022xx

Accepted

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

Tip: Used for asynchronous operations where the result is not immediately available.

2042xx

No Content

The server has successfully fulfilled the request but does not need to return an entity-body.

Tip: Common after a successful DELETE request or a PUT that doesn't return content.

2062xx

Partial Content

The server has fulfilled the partial GET request for the resource.

Tip: Used for resumable downloads and video streaming with range requests.

3003xx

Multiple Choices

The requested resource has multiple representations, each with its own URI.

Tip: Rarely used; the server should indicate a preferred choice.

3013xx

Moved Permanently

The requested resource has been assigned a new permanent URI.

Tip: Use for permanent URL changes. Search engines will update their index to the new URL.

3023xx

Found

The requested resource resides temporarily under a different URI.

Tip: Commonly used for temporary redirects. However, 307 is preferred for preserving the HTTP method.

3033xx

See Other

The response to the request can be found under another URI using a GET method.

Tip: Used after a POST to redirect the client to a confirmation page via GET.

3043xx

Not Modified

The resource has not been modified since the last request.

Tip: Essential for browser caching. No body is sent with this response.

3073xx

Temporary Redirect

The requested resource resides temporarily under a different URI, preserving the request method.

Tip: Preferred over 302 when you need to ensure the HTTP method is not changed.

3083xx

Permanent Redirect

The resource is now permanently located at another URI, preserving the request method.

Tip: Preferred over 301 when you need to ensure the HTTP method is not changed.

4004xx

Bad Request

The server cannot process the request due to client error (e.g., malformed request syntax).

Tip: Validate input on the client side before sending requests to avoid this error.

4014xx

Unauthorized

The request requires user authentication.

Tip: The client must authenticate itself to get the requested response. Check your API keys or tokens.

4034xx

Forbidden

The server understood the request but refuses to authorize it.

Tip: Unlike 401, authentication will not help. The user does not have permission for this resource.

4044xx

Not Found

The requested resource could not be found on the server.

Tip: Check the URL for typos. This is the most common error on the web.

4054xx

Method Not Allowed

The method received in the request is not supported by the target resource.

Tip: Check if you are using the correct HTTP method (GET, POST, PUT, DELETE, etc.).

4084xx

Request Timeout

The server did not receive a complete request within the time it was prepared to wait.

Tip: The client may retry the request without modifications.

4094xx

Conflict

The request could not be completed due to a conflict with the current state of the resource.

Tip: Common when trying to create a resource that already exists or edit with stale data.

4104xx

Gone

The requested resource is no longer available and no forwarding address is known.

Tip: Unlike 404, this indicates the resource was intentionally removed permanently.

4224xx

Unprocessable Entity

The server understands the content type and syntax but was unable to process the instructions.

Tip: Common in API validation when the data format is correct but values are invalid.

4294xx

Too Many Requests

The user has sent too many requests in a given amount of time (rate limiting).

Tip: Implement exponential backoff and respect the Retry-After header.

5005xx

Internal Server Error

The server encountered an unexpected condition that prevented it from fulfilling the request.

Tip: Check server logs for the root cause. This is a catch-all for unhandled server errors.

5015xx

Not Implemented

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

Tip: The server does not recognize the request method or lacks the ability to fulfill it.

5025xx

Bad Gateway

The server received an invalid response from an upstream server it accessed while fulfilling the request.

Tip: Often occurs when a reverse proxy cannot reach the application server behind it.

5035xx

Service Unavailable

The server is currently unable to handle the request due to temporary overloading or maintenance.

Tip: This is typically temporary. Check the Retry-After header for when to retry.

5045xx

Gateway Timeout

The server did not receive a timely response from an upstream server.

Tip: The upstream server is taking too long to respond. Check if the backend service is healthy.

5055xx

HTTP Version Not Supported

The server does not support the HTTP protocol version used in the request.

Tip: Ensure you are using HTTP/1.1 or HTTP/2 as supported by the server.

HTTP Status Code Reference: Complete Guide for Developers

Understanding HTTP Status Codes

HTTP status codes are three-digit numbers returned by a server in response to a client's request made to the server. They are a fundamental part of the Hypertext Transfer Protocol (HTTP), which governs the communication between web browsers (clients) and web servers. Every time you visit a website, click a link, or submit a form, your browser sends an HTTP request, and the server responds with a status code along with the requested content (or an explanation of why the request could not be fulfilled). Understanding these codes is essential for web developers, system administrators, and anyone who works with web technologies, as they provide critical information about the success or failure of HTTP requests.

The HTTP status code system was first defined in HTTP/1.0 (RFC 1945) in 1996 and has been expanded in subsequent specifications, most notably HTTP/1.1 (RFC 7231) and HTTP/2 (RFC 7540). The system was designed to be extensible—while the IANA (Internet Assigned Numbers Authority) maintains an official registry of standard status codes, custom codes can be defined for specific applications. Despite this flexibility, the vast majority of web traffic involves only about a dozen commonly used status codes. The first digit of the status code defines its class, making it easy to categorize responses at a glance: 1xx for informational, 2xx for success, 3xx for redirection, 4xx for client errors, and 5xx for server errors.

Status codes are always accompanied by a reason phrase—a brief textual description of the status—which is intended for human consumption. For example, 404 comes with "Not Found," and 200 comes with "OK." While the reason phrase is optional in HTTP/2 and later versions (which use binary framing), it remains a useful shorthand for understanding responses. Developers should not rely solely on reason phrases in their code, as these can vary between servers, but should instead check the numeric status code, which is standardized and unambiguous. Our HTTP Status Code Reference provides both the numeric codes and their standard reason phrases, along with practical descriptions and usage tips for each code.

Status Code Categories

The five categories of HTTP status codes serve distinct purposes in the request-response cycle. Informational responses (1xx) indicate that the server has received the request and is continuing the process. These are relatively rare in everyday web browsing but play an important role in specific scenarios. The 100 Continue code, for example, allows a client to check whether the server is willing to accept a large request body before actually sending it, saving bandwidth in cases where the server would reject the request based on the headers alone. The 101 Switching Protocols code enables the client and server to negotiate a protocol upgrade, most commonly used when establishing WebSocket connections from an HTTP endpoint.

Successful responses (2xx) indicate that the client's request was received, understood, and accepted by the server. The most common is 200 OK, which simply means the request succeeded. However, there are important nuances: 201 Created specifically indicates that a new resource was created (typically in response to a POST request), 202 Accepted means the request was accepted but processing is ongoing, and 204 No Content indicates success without returning any body (useful for DELETE or PUT operations). The 206 Partial Content response is essential for resumable downloads and media streaming, allowing clients to request specific byte ranges of a resource rather than downloading the entire file.

Redirection responses (3xx) tell the client that additional action is needed to complete the request. The key distinction here is between permanent and temporary redirects. 301 Moved Permanently and 308 Permanent Redirect indicate that the resource has permanently moved to a new URL, and search engines should update their indexes. 302 Found and 307 Temporary Redirect indicate a temporary change. The critical difference between 301/302 and 307/308 is that the newer codes (307/308) preserve the original HTTP method, whereas the older codes (301/302) may cause the method to change from POST to GET. The 304 Not Modified code is perhaps the most frequently encountered 3xx code—it enables efficient caching by telling the client that the cached version of a resource is still valid, eliminating the need to re-download unchanged content.

Most Common Status Codes Explained

The 404 Not Found error is undoubtedly the most widely recognized HTTP status code among general internet users. It indicates that the server cannot find the requested resource, which typically means the URL is incorrect, the page has been removed, or the link is broken. While 404 is often seen as simply an error, it actually serves an important purpose: it tells both users and search engines that the resource does not exist at the requested location. Properly handling 404 errors with helpful custom error pages that suggest alternative content or provide navigation aids is an important aspect of user experience design and SEO. Websites should also monitor their 404 logs to identify broken links and missing resources.

The 401 Unauthorized and 403 Forbidden codes are frequently confused but have distinct meanings. A 401 response means the client has not provided valid authentication credentials—the user needs to log in or provide a valid API key or token. A 403 response means the server understood the request and recognized the user's identity, but the user does not have permission to access the requested resource. In other words, 401 means "I do not know who you are" and 403 means "I know who you are, but you are not allowed to do this." Correctly using these codes helps API consumers implement proper authentication flows and error handling.

On the server error side, 500 Internal Server Error is the most common and also the most frustrating, because it provides very little information about what went wrong. It is a catch-all response that indicates the server encountered an unexpected condition that prevented it from fulfilling the request. Debugging a 500 error requires access to server logs, as the actual error details are typically hidden from the client for security reasons. The 502 Bad Gateway and 504 Gateway Timeout errors are common in architectures that use reverse proxies or load balancers. A 502 means the proxy received an invalid response from the upstream server, while a 504 means the upstream server did not respond within the allowed time period. Both of these errors often indicate infrastructure problems rather than application bugs, such as the backend service being down, overloaded, or unreachable.

Troubleshooting with Status Codes

HTTP status codes are your first and most valuable clue when debugging web application issues. A systematic approach to interpreting these codes can dramatically reduce the time it takes to identify and fix problems. Start by categorizing the error: 4xx codes point to client-side issues (the request itself is wrong), while 5xx codes point to server-side issues (the server failed to process a valid request). This distinction immediately narrows your search space. For 4xx errors, check the request URL, headers, body format, authentication credentials, and permissions. For 5xx errors, check server logs, application error reports, resource utilization, and upstream service availability.

When building APIs, choosing the correct status code for each response is crucial for API usability and adherence to REST principles. Use 200 for successful reads and updates, 201 for resource creation, 204 for successful deletes, 400 for malformed requests, 401 for missing or invalid authentication, 403 for insufficient permissions, 404 for missing resources, 409 for conflicts (such as duplicate entries), and 422 for validation errors where the request format is correct but the data values are invalid. The 422 Unprocessable Entity code is particularly useful for API validation errors because it distinguishes "the data is syntactically valid but semantically wrong" from "the request itself is malformed" (400). This distinction helps API consumers implement more precise error handling and provide more helpful error messages to their users.

Monitoring HTTP status codes in production is essential for maintaining application health and user experience. Set up alerting on increased rates of 5xx errors, which indicate server problems requiring immediate attention. Track 4xx error rates to identify broken links, API misuse, or potential security probing. Monitor 301/302 redirects to ensure they are intentional and not causing unnecessary latency from redirect chains. Pay special attention to 429 Too Many Requests responses, which may indicate rate limiting is working correctly but could also mean legitimate users are being throttled. By using our HTTP Status Code Reference alongside proper monitoring tools, you can quickly identify, understand, and resolve issues that manifest through HTTP status codes, keeping your web applications running smoothly and your users satisfied.