Complete Guide to HTTP Status Codes: Meanings, Categories, and Examples

URL Slug: complete-guide-http-status-codes

Introduction

HTTP status codes are three-digit numbers returned by a server to indicate the result of an HTTP request. They help web browsers, mobile applications, API clients, developers, and other systems understand whether a request succeeded, requires further action, encountered a problem, or could not be completed.

When a user opens a website, submits a form, uploads a file, or requests information from an API, the server typically returns an HTTP status code along with response headers and, when appropriate, a response body.

Understanding HTTP status codes is essential for web development, API integration, server administration, application debugging, network troubleshooting, and system monitoring.

1. Understanding HTTP Status Code Categories

HTTP status codes are divided into five categories according to their first digit.

These categories provide a general interpretation. The exact meaning depends on the individual status code and the HTTP method used.

2. Informational Status Codes: 1xx

Informational status codes indicate that the server has received part of a request or is communicating preliminary information before the final response. These responses are generally temporary and do not represent the final outcome of the request.

100 Continue

The server has received the initial request headers and indicates that the client may continue sending the request body.

Example: A client is uploading a large file and wants confirmation that the server has not rejected the request before transmitting the file contents.

101 Switching Protocols

The server agrees to switch to a different protocol as requested by the client.

Example: A client requests a protocol upgrade from HTTP to WebSocket, and the server accepts the upgrade.

102 Processing

The server has received the request and is processing it, but the final response is not yet available. This status code originated in WebDAV and is uncommon.

Example: A legacy WebDAV implementation reports that a complex operation is still being processed.

103 Early Hints

The server sends preliminary response headers that allow a client to begin preparing resources before the final response arrives.

Example: A browser starts preloading a stylesheet while the server continues generating the main page.

104 Upload Resumption Supported

This temporary registered extension indicates support for resumable uploads. Its registration has a separate expiration condition and should be checked in the current IANA registry before relying on it.

Example: A client and server negotiate support for resuming an interrupted upload.

3. Successful Status Codes: 2xx

Successful status codes indicate that the request was successfully received, understood, and accepted. Depending on the code, the server may return a representation, create a resource, or complete an operation without returning a response body.

200 OK

The request succeeded. This is one of the most frequently encountered HTTP status codes.

Examples: Retrieving a webpage, fetching user information from an API, successfully updating a resource, or returning search results.

201 Created

The request succeeded, and one or more resources were created. The response often includes a Location header identifying the newly created resource.

Example: An API successfully creates a new user account after receiving a POST request.

202 Accepted

The request has been accepted for processing, but processing has not necessarily completed. This code does not guarantee that the operation will eventually succeed.

Example: A server accepts a request to generate a report and schedules it for background processing.

203 Non-Authoritative Information

The request succeeded, but the returned representation has been modified by an intermediary rather than being provided exactly as the origin server supplied it.

204 No Content

The request succeeded, but the server has no additional response content to send.

Example: An API successfully processes an update and does not need to return a response body.

205 Reset Content

The request succeeded, and the client is instructed to reset the document view that initiated the request.

206 Partial Content

The server returns only the requested portion of a resource, generally in response to a range request.

Example: A media player requests a specific section of a video file instead of downloading the entire file.

207 Multi-Status

This WebDAV status code communicates information about multiple operations or resources within a single response. The response body typically contains details about individual results.

208 Already Reported

This WebDAV status code indicates that a resource has already been reported in an earlier part of the current multistatus response.

226 IM Used

The server has fulfilled a GET request and is returning a representation that reflects an instance manipulation. This code is associated with HTTP delta encoding.

4. Redirection Status Codes: 3xx

Redirection status codes indicate that a client may need to retrieve a resource from another location or take another action to complete its request.

300 Multiple Choices

The requested resource has multiple available representations, and the server indicates that more than one option is available.

301 Moved Permanently

The requested resource has permanently moved to another URL. Clients and search engines can use the new location when appropriate.

302 Found

The requested resource is temporarily available at another URL. For historical compatibility, clients commonly follow this redirect while potentially changing a POST request to GET.

303 See Other

The client should retrieve another resource, usually using GET or HEAD, at the location specified by the server.

Example: After a form submission, the server redirects the browser to a page displaying the result.

304 Not Modified

The requested resource has not changed according to the conditions supplied by the client. The client can reuse its cached representation rather than downloading the resource again.

305 Use Proxy

This status code historically indicated that the client should access the resource through a specified proxy. It is deprecated and should not be used in modern implementations.

306 Unused

This status code is reserved as unused and has no current operational meaning for normal HTTP responses.

307 Temporary Redirect

The requested resource is temporarily available at another URL. A client following a 307 redirect must not change the request method.

308 Permanent Redirect

The requested resource has permanently moved to another URL. Like 307, it preserves the request method when the client follows the redirect.

Important distinction: A 301 or 302 redirect may involve historical POST-to-GET behavior in clients. A 307 or 308 redirect preserves the original request method.

5. Client Error Status Codes: 4xx

Client error status codes indicate that a request cannot be fulfilled because of an issue involving the request, its authorization, its conditions, or the requested resource. The term client error does not always mean that the end user made a mistake. An application, proxy, authentication layer, or intermediary may be responsible.

400 Bad Request

The server cannot process the request because it considers the request invalid.

Example: An API receives malformed JSON or invalid request syntax.

401 Unauthorized

The request lacks valid authentication credentials for the requested resource. Despite its name, this code generally indicates that authentication is required or has failed.

402 Payment Required

This status code is reserved for future use in the core HTTP specification. Some services use it for payment-related restrictions, but its precise meaning depends on the implementation.

403 Forbidden

The server understands the request but refuses to fulfill it. Valid authentication does not necessarily grant permission to access a resource.

404 Not Found

The server cannot find a current representation of the requested resource, or it is unwilling to disclose whether one exists.

Examples: A webpage does not exist, an API references an unknown resource identifier, or a requested file cannot be found.

405 Method Not Allowed

The request method is not supported for the target resource. The response should include an Allow header identifying supported methods.

406 Not Acceptable

The server cannot provide a representation that satisfies the client's acceptable response formats or other relevant content negotiation preferences.

407 Proxy Authentication Required

The client must authenticate with a proxy before the request can proceed.

408 Request Timeout

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

409 Conflict

The request conflicts with the current state of the target resource.

Example: A client attempts to update a resource using incompatible state information.

410 Gone

The requested resource is no longer available, and the server indicates that this condition is likely to be permanent.

411 Length Required

The server refuses to accept the request without a required Content-Length header.

412 Precondition Failed

One or more conditions supplied in the request headers evaluated to false.

Example: A client attempts to update a resource only if its entity tag matches, but the resource has changed.

413 Content Too Large

The server refuses to process the request because its content exceeds the limit it is willing or able to process.

414 URI Too Long

The server refuses to process a request because the target URI is longer than it is willing to interpret.

415 Unsupported Media Type

The server refuses to process the request because the format of its content is not supported for the requested operation.

416 Range Not Satisfiable

The server cannot satisfy the requested range of a resource.

417 Expectation Failed

The server cannot satisfy the expectations expressed in the request's Expect header.

418 Unused

The core HTTP specification marks this status code as unused. The phrase "I'm a teapot" originated in an April Fools' Day specification. It remains a well-known reference in developer culture, but it is not an active standard error meaning for ordinary HTTP applications.

421 Misdirected Request

The request was directed to a server that cannot produce a response for the target origin.

422 Unprocessable Content

The server understands the content type and the syntax of the request, but it cannot process the instructions contained in the request.

Example: An API receives valid JSON containing a date or value that violates a business rule.

423 Locked

This WebDAV status code indicates that the requested resource is locked.

424 Failed Dependency

This WebDAV status code indicates that the requested operation failed because another operation on which it depended also failed.

425 Too Early

The server is unwilling to process a request that might be replayed. This code is associated with protections against replay risks involving early data in TLS connections.

426 Upgrade Required

The server refuses to perform the request using the current protocol and indicates that a protocol upgrade is required. The response includes an Upgrade header.

428 Precondition Required

The server requires the request to be conditional. This can help prevent lost updates when multiple clients modify the same resource.

429 Too Many Requests

The client has sent too many requests within a given period. This status code is commonly associated with rate limiting. A response may include a Retry-After header.

431 Request Header Fields Too Large

The server refuses to process the request because its request headers, individually or collectively, are too large.

451 Unavailable For Legal Reasons

The server cannot provide the requested resource because of a legal restriction.

6. Server Error Status Codes: 5xx

Server error status codes indicate that the server failed to fulfill an apparently valid request. These errors may originate from the application, infrastructure, gateway, proxy, database dependency, or another component required to complete the request.

500 Internal Server Error

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

Examples: An unhandled application exception, an unexpected database failure, or an unforeseen runtime error.

501 Not Implemented

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

502 Bad Gateway

A server acting as a gateway or proxy received an invalid response from an upstream server.

503 Service Unavailable

The server is temporarily unable to handle the request. Common causes include maintenance, overload, or temporary service unavailability. A Retry-After header may indicate when the client should try again.

504 Gateway Timeout

A server acting as a gateway or proxy did not receive a timely response from an upstream server.

505 HTTP Version Not Supported

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

506 Variant Also Negotiates

The server encounters an internal configuration problem during transparent content negotiation.

507 Insufficient Storage

This WebDAV status code indicates that the server cannot store the information needed to complete the request.

508 Loop Detected

This WebDAV status code indicates that the server detected an infinite loop while processing a request.

510 Not Extended

This status code originated in an HTTP extension framework that is now obsolete. It is not generally used by modern web applications.

511 Network Authentication Required

The client must authenticate to gain network access. This code is intended for network intermediaries, such as captive portals, rather than as a general application authentication response.

7. Frequently Used HTTP Status Codes at a Glance

8. Important Differences Between Similar Status Codes

401 vs. 403

401 Unauthorized generally indicates that valid authentication credentials are missing or unavailable. 403 Forbidden indicates that the server refuses access, even when the request may already be authenticated.

400 vs. 422

400 Bad Request indicates that the request is invalid or cannot be processed because of a request-level problem. 422 Unprocessable Content indicates that the server understands the content and its syntax but cannot process the instructions. For example, malformed JSON commonly produces 400, while syntactically valid JSON containing a value that violates application rules may produce 422.

404 vs. 410

404 Not Found indicates that the server cannot find a current representation of the resource or does not disclose its existence. 410 Gone indicates that the resource is no longer available and that the removal is likely permanent.

301 vs. 302

301 Moved Permanently communicates a permanent redirect. 302 Found communicates a temporary redirect. These codes may influence caching, browser behavior, and search engine handling.

307 vs. 308

307 Temporary Redirect preserves the request method during a temporary redirect. 308 Permanent Redirect preserves the request method during a permanent redirect.

502 vs. 503 vs. 504

502 Bad Gateway means that a gateway or proxy received an invalid response from an upstream server. 503 Service Unavailable means that the server is temporarily unable to handle the request. 504 Gateway Timeout means that a gateway or proxy did not receive a timely upstream response.

9. HTTP Status Codes in REST APIs

HTTP status codes help REST APIs communicate the outcome of a request in a consistent format.

Retrieving a Resource

A successful GET request commonly returns 200 OK. If the requested resource cannot be found, the server may return 404 Not Found.

Creating a Resource

A successful POST request that creates a resource commonly returns 201 Created. The response may include the new resource's representation and a Location header.

Accepting Background Work

A request that has been accepted but has not finished processing may return 202 Accepted. The API can provide an operation identifier or URL that the client can use to check the processing status.

Updating a Resource

An update may return 200 OK when a response representation is provided or 204 No Content when the operation succeeds without a response body.

Deleting a Resource

A successful DELETE request may return 204 No Content when no response body is necessary, or 200 OK when the server returns a representation describing the result.

Handling Invalid Data

An API may return 400 Bad Request for malformed input and 422 Unprocessable Content for content that is syntactically valid but violates application rules.

Handling Rate Limits

An API may return 429 Too Many Requests when a client exceeds its request allowance. The client should follow the API's documented retry policy and respect any applicable Retry-After header.

10. How Developers Should Handle HTTP Status Codes

Validate the Response

Clients should inspect the HTTP status code rather than assuming that every response represents success. A response body can contain useful diagnostic information, but its presence does not automatically mean that the request succeeded.

Use Appropriate Error Handling

Applications should distinguish between client errors and server errors. A validation error may require the user to correct input, while a temporary server failure may justify a retry.

Avoid Blind Retries

Not every failed request should be retried automatically. Repeating a non-idempotent operation can create duplicate transactions or resources. Clients should consider the request method, operation semantics, idempotency mechanisms, rate limits, and server guidance before retrying.

Respect Retry-After

When a response includes a Retry-After header, clients should follow it where applicable. This is particularly important for rate limiting and temporary service unavailability.

Protect Sensitive Information

Server error responses should not expose passwords, access tokens, internal file paths, stack traces, database credentials, or other sensitive implementation details. Detailed diagnostic information should be recorded securely in server-side logs rather than exposed indiscriminately to clients.

Monitor Error Rates

Operational monitoring should track relevant status codes over time. A sudden increase in 5xx responses may indicate an infrastructure or application problem. A high number of 401 or 403 responses may indicate authentication failures or access-control issues. An increase in 429 responses may indicate that clients are exceeding configured rate limits.

Status codes should be interpreted alongside request latency, logs, traces, and application-specific metrics.

11. Standard Status Codes, Unassigned Values, and Custom Responses

Not every three-digit number within the range from 100 to 599 represents an assigned standard HTTP status code. The Internet Assigned Numbers Authority maintains the official HTTP Status Code Registry, which records registered status codes and their specifications.

Some values are assigned to established standards, while others are unassigned, reserved, unused, obsolete, or temporarily registered. For example, 418 is marked unused in the current core HTTP specification, while 510 Not Extended is obsolete. The temporary registration for 104 Upload Resumption Supported has a separate expiration condition.

Servers and intermediaries may also generate non-standard status codes. Such responses should not automatically be interpreted as standardized HTTP behavior. Cloud platforms, reverse proxies, application frameworks, and API gateways sometimes use provider-specific error codes or messages. Their meanings depend on the relevant provider's documentation.

When developing interoperable applications, prefer registered HTTP status codes and document any non-standard behavior explicitly.

12. Frequently Asked Questions

What is the most common HTTP success code?

200 OK is one of the most common success responses. Other success codes may be more appropriate for specific operations.

What does HTTP 201 mean?

201 Created means that the request succeeded and created one or more resources.

What does HTTP 204 mean?

204 No Content means that the request succeeded and the server is not returning additional response content.

What does HTTP 404 mean?

404 Not Found means that the server cannot find a current representation of the requested resource or is not willing to disclose whether it exists.

What does HTTP 500 mean?

500 Internal Server Error indicates an unexpected server-side condition that prevented the request from being fulfilled.

Are all 4xx responses caused by users?

No. A 4xx response indicates a request-related problem, but the underlying cause may involve the client application, authentication configuration, an intermediary, or server-side access policies.

Are all 5xx responses caused by the application server?

No. A 5xx response may originate from an application server, reverse proxy, gateway, or another server-side component. The exact cause requires investigation.

Can a successful request return an empty body?

Yes. 204 No Content explicitly indicates a successful response without response content.

Are HTTP status codes the same as application error codes?

No. HTTP status codes describe the HTTP-level result of a request. An application may also define its own error codes inside a JSON response or another representation. An API, for example, may return 400 Bad Request together with an application-specific code identifying a missing field.

Where can the official list of HTTP status codes be found?

The authoritative registry is maintained by the Internet Assigned Numbers Authority. The HTTP Semantics specification, RFC 9110, defines the principal status code classes and many of their meanings.

Conclusion

HTTP status codes are a fundamental part of web communication. They allow clients and servers to communicate request outcomes in a consistent and widely understood format.

The five categories provide a practical starting point: 1xx responses communicate preliminary information, 2xx responses indicate success, 3xx responses indicate redirection, 4xx responses identify request-related problems, and 5xx responses indicate server-side failures.

Understanding the differences between individual codes, such as 401 and 403, 301 and 302, or 502 and 504, helps developers build more reliable applications and troubleshoot problems more efficiently.

For production systems, HTTP status codes should be selected according to the applicable standards, documented API behavior, and actual outcome of each operation. Using them consistently improves interoperability, observability, error handling, and the overall quality of web services.

References

1. Internet Assigned Numbers Authority. Hypertext Transfer Protocol Status Code Registry.
2. Internet Engineering Task Force. RFC 9110, HTTP Semantics.
3. Mozilla Developer Network. HTTP Response Status Codes.