HTTP Status Code Cheat Sheet

A complete, printable reference of every standard HTTP status code organized by category. Bookmark this page for quick lookups during development.

How HTTP Status Codes Work

Every HTTP response includes a three-digit status code that tells the client what happened with its request. The first digit defines the class of the response. There are five classes, each serving a distinct purpose in the request-response lifecycle. Understanding these classes is the foundation for debugging network issues, designing APIs, and building robust web applications.

This cheat sheet covers all standard codes defined in RFC 9110 (HTTP Semantics), along with widely-used extension codes from RFC 6585, RFC 7725, and RFC 8470. For an interactive lookup experience, use our HTTP Status Code Reference tool to search by code, browse by category, or navigate the decision tree.

1xx Informational

Informational responses indicate that the server has received the request and is continuing to process it. These codes are provisional; the client should expect a final response to follow. In practice, most developers rarely encounter 1xx codes directly because HTTP client libraries handle them transparently.

Code	Name	Description
`100`	Continue	The server has received the request headers and the client should proceed to send the request body. Used with the `Expect: 100-continue` header to avoid sending large payloads to servers that will reject them.
`101`	Switching Protocols	The server agrees to switch protocols as requested by the client via the `Upgrade` header. Most commonly seen during WebSocket handshakes when upgrading from HTTP to the WebSocket protocol.
`102`	Processing	The server has received and is processing the request, but no response is available yet. Defined by WebDAV (RFC 2518) to prevent clients from timing out during long-running operations.
`103`	Early Hints	Used to return response headers before the final response. Allows the browser to start preloading resources (CSS, fonts, scripts) while the server is still preparing the full response. Defined in RFC 8297.

2xx Success

Success codes confirm that the client's request was received, understood, and accepted. These are the codes you want to see in your application logs. The specific 2xx code communicates nuance about how the request was handled, which matters for caching, client behavior, and API design.

Code	Name	Description
`200`	OK	The standard success response. The response body contains the requested resource (for GET), the result of the action (for POST), or a representation of the resource (for other methods). The most common HTTP status code.
`201`	Created	The request succeeded and a new resource was created. Typically returned by POST requests. The response should include a `Location` header with the URI of the new resource.
`202`	Accepted	The request has been accepted for processing, but the processing has not been completed. Used for asynchronous operations where the server queues work for later execution.
`204`	No Content	The request succeeded but there is no content to return. Commonly used for DELETE operations or PUT updates where no response body is needed. The client should not navigate away from the current page.
`206`	Partial Content	The server is delivering only part of the resource due to a `Range` header in the request. Essential for resumable downloads, video streaming, and large file transfers.

3xx Redirection

Redirection codes indicate that further action is needed from the client to complete the request. The most important distinction in this category is between permanent (301, 308) and temporary (302, 307) redirects, which affects caching, SEO, and how clients handle the redirect. For a deep dive into the two most confused codes in this category, read our guide on 301 vs 302 redirects.

Code	Name	Description
`301`	Moved Permanently	The resource has permanently moved to the URL given by the `Location` header. Clients should update bookmarks and cached links. Search engines transfer SEO value (link equity) to the new URL.
`302`	Found	The resource is temporarily at a different URL. The client should continue using the original URL for future requests. Historically, some clients changed POST to GET on redirect (which led to 307).
`304`	Not Modified	The resource has not been modified since the version specified by the `If-Modified-Since` or `If-None-Match` headers. The client should use its cached copy. No response body is sent.
`307`	Temporary Redirect	Like 302, but guarantees that the HTTP method and body will not change during the redirect. If the original request was POST, the redirected request will also be POST.
`308`	Permanent Redirect	Like 301, but guarantees that the HTTP method and body will not change. The permanent counterpart to 307. Use this when you need a permanent redirect that preserves the request method.

4xx Client Error

Client error codes indicate that the request contains bad syntax or cannot be fulfilled. These codes tell the client that something about its request was wrong and it should not retry without modification. Choosing the right 4xx code in your API is critical for developer experience. Read our API status code best practices guide for detailed recommendations.

Code	Name	Description
`400`	Bad Request	The server cannot process the request due to something perceived to be a client error (malformed syntax, invalid parameters, deceptive request routing). The catch-all for client-side problems.
`401`	Unauthorized	The request requires authentication. The client must authenticate itself to get the requested response. Despite the name, this code is about authentication (identity), not authorization (permissions).
`403`	Forbidden	The client is authenticated but does not have permission to access the requested resource. Unlike 401, re-authenticating will not help. The server understood the request but refuses to authorize it.
`404`	Not Found	The server cannot find the requested resource. In APIs, this can also be used to mask the existence of a resource from unauthorized clients. The most widely recognized HTTP status code.
`405`	Method Not Allowed	The request method (GET, POST, PUT, etc.) is not supported for the requested resource. The response must include an `Allow` header listing the supported methods.
`409`	Conflict	The request conflicts with the current state of the resource. Commonly used for concurrent modification errors, duplicate resource creation, or version conflicts in APIs.
`422`	Unprocessable Content	The server understands the content type and syntax of the request, but was unable to process the contained instructions. Used for semantic validation errors in APIs (e.g., invalid email format).
`429`	Too Many Requests	The user has sent too many requests in a given time period (rate limiting). The response should include a `Retry-After` header indicating how long to wait before making a new request.

5xx Server Error

Server error codes indicate that the server failed to fulfill a valid request. These codes mean the problem is on the server side, not the client. For a systematic debugging approach to these errors, see our 5xx troubleshooting guide.

Code	Name	Description
`500`	Internal Server Error	A generic error message indicating that the server encountered an unexpected condition. Often caused by unhandled exceptions, misconfigured servers, or application bugs.
`502`	Bad Gateway	The server, acting as a gateway or proxy, received an invalid response from the upstream server. Common when a reverse proxy (Nginx, CloudFront) cannot reach the application server.
`503`	Service Unavailable	The server is not ready to handle the request. Usually caused by maintenance, overloaded servers, or temporary capacity issues. Should include a `Retry-After` header when possible.
`504`	Gateway Timeout	The server, acting as a gateway or proxy, did not receive a timely response from the upstream server. Often indicates slow backend processing, database query timeouts, or network issues.

Less Common but Important Codes

Beyond the codes listed above, several less-common status codes deserve mention because they solve specific problems that the more generic codes cannot:

203 Non-Authoritative Information: The response has been modified by a transforming proxy. The original response was 200, but the proxy has altered headers or body content.
410 Gone: Like 404, but permanent. The resource existed but has been intentionally removed and will not return. Search engines will remove the URL from their index faster than with a 404.
413 Content Too Large: The request body exceeds the server's configured maximum. Common with file upload endpoints that enforce size limits.
415 Unsupported Media Type: The server refuses the request because the payload format is not supported. Returned when the Content-Type header does not match what the endpoint expects.
451 Unavailable For Legal Reasons: The server is denying access to the resource as a consequence of a legal demand. Named after Fahrenheit 451, Ray Bradbury's novel about censorship.
511 Network Authentication Required: The client needs to authenticate to gain network access, typically seen with captive portals in hotels, airports, and coffee shops.

Quick Reference Rules

When choosing a status code for your API response, these rules cover the majority of cases:

Successful GET or PUT: return 200
Successful POST that creates a resource: return 201 with a Location header
Successful DELETE: return 204 (no body needed)
Accepted but processing later: return 202
Bad request data or missing fields: return 400
Validation errors (correct syntax, wrong semantics): return 422
Not logged in: return 401
Logged in but lacks permissions: return 403
Resource does not exist: return 404
Rate limited: return 429 with Retry-After
Server broke: return 500 and investigate immediately

For more detailed API design guidance, read our API Status Code Best Practices article. To look up any specific code, use the HTTP Status Code Reference tool.

More DevPane Tools

HTTP Status Code Cheat Sheet

A complete, printable reference of every standard HTTP status code organized by category. Bookmark this page for quick lookups during development.

How HTTP Status Codes Work

1xx Informational

Code	Name	Description
`100`	Continue	The server has received the request headers and the client should proceed to send the request body. Used with the `Expect: 100-continue` header to avoid sending large payloads to servers that will reject them.
`101`	Switching Protocols	The server agrees to switch protocols as requested by the client via the `Upgrade` header. Most commonly seen during WebSocket handshakes when upgrading from HTTP to the WebSocket protocol.
`102`	Processing	The server has received and is processing the request, but no response is available yet. Defined by WebDAV (RFC 2518) to prevent clients from timing out during long-running operations.
`103`	Early Hints	Used to return response headers before the final response. Allows the browser to start preloading resources (CSS, fonts, scripts) while the server is still preparing the full response. Defined in RFC 8297.

2xx Success

Code	Name	Description
`200`	OK	The standard success response. The response body contains the requested resource (for GET), the result of the action (for POST), or a representation of the resource (for other methods). The most common HTTP status code.
`201`	Created	The request succeeded and a new resource was created. Typically returned by POST requests. The response should include a `Location` header with the URI of the new resource.
`202`	Accepted	The request has been accepted for processing, but the processing has not been completed. Used for asynchronous operations where the server queues work for later execution.
`204`	No Content	The request succeeded but there is no content to return. Commonly used for DELETE operations or PUT updates where no response body is needed. The client should not navigate away from the current page.
`206`	Partial Content	The server is delivering only part of the resource due to a `Range` header in the request. Essential for resumable downloads, video streaming, and large file transfers.

3xx Redirection

Code	Name	Description
`301`	Moved Permanently	The resource has permanently moved to the URL given by the `Location` header. Clients should update bookmarks and cached links. Search engines transfer SEO value (link equity) to the new URL.
`302`	Found	The resource is temporarily at a different URL. The client should continue using the original URL for future requests. Historically, some clients changed POST to GET on redirect (which led to 307).
`304`	Not Modified	The resource has not been modified since the version specified by the `If-Modified-Since` or `If-None-Match` headers. The client should use its cached copy. No response body is sent.
`307`	Temporary Redirect	Like 302, but guarantees that the HTTP method and body will not change during the redirect. If the original request was POST, the redirected request will also be POST.
`308`	Permanent Redirect	Like 301, but guarantees that the HTTP method and body will not change. The permanent counterpart to 307. Use this when you need a permanent redirect that preserves the request method.

4xx Client Error

Code	Name	Description
`400`	Bad Request	The server cannot process the request due to something perceived to be a client error (malformed syntax, invalid parameters, deceptive request routing). The catch-all for client-side problems.
`401`	Unauthorized	The request requires authentication. The client must authenticate itself to get the requested response. Despite the name, this code is about authentication (identity), not authorization (permissions).
`403`	Forbidden	The client is authenticated but does not have permission to access the requested resource. Unlike 401, re-authenticating will not help. The server understood the request but refuses to authorize it.
`404`	Not Found	The server cannot find the requested resource. In APIs, this can also be used to mask the existence of a resource from unauthorized clients. The most widely recognized HTTP status code.
`405`	Method Not Allowed	The request method (GET, POST, PUT, etc.) is not supported for the requested resource. The response must include an `Allow` header listing the supported methods.
`409`	Conflict	The request conflicts with the current state of the resource. Commonly used for concurrent modification errors, duplicate resource creation, or version conflicts in APIs.
`422`	Unprocessable Content	The server understands the content type and syntax of the request, but was unable to process the contained instructions. Used for semantic validation errors in APIs (e.g., invalid email format).
`429`	Too Many Requests	The user has sent too many requests in a given time period (rate limiting). The response should include a `Retry-After` header indicating how long to wait before making a new request.

5xx Server Error

Code	Name	Description
`500`	Internal Server Error	A generic error message indicating that the server encountered an unexpected condition. Often caused by unhandled exceptions, misconfigured servers, or application bugs.
`502`	Bad Gateway	The server, acting as a gateway or proxy, received an invalid response from the upstream server. Common when a reverse proxy (Nginx, CloudFront) cannot reach the application server.
`503`	Service Unavailable	The server is not ready to handle the request. Usually caused by maintenance, overloaded servers, or temporary capacity issues. Should include a `Retry-After` header when possible.
`504`	Gateway Timeout	The server, acting as a gateway or proxy, did not receive a timely response from the upstream server. Often indicates slow backend processing, database query timeouts, or network issues.

Less Common but Important Codes

Beyond the codes listed above, several less-common status codes deserve mention because they solve specific problems that the more generic codes cannot:

203 Non-Authoritative Information: The response has been modified by a transforming proxy. The original response was 200, but the proxy has altered headers or body content.
410 Gone: Like 404, but permanent. The resource existed but has been intentionally removed and will not return. Search engines will remove the URL from their index faster than with a 404.
413 Content Too Large: The request body exceeds the server's configured maximum. Common with file upload endpoints that enforce size limits.
415 Unsupported Media Type: The server refuses the request because the payload format is not supported. Returned when the Content-Type header does not match what the endpoint expects.
451 Unavailable For Legal Reasons: The server is denying access to the resource as a consequence of a legal demand. Named after Fahrenheit 451, Ray Bradbury's novel about censorship.
511 Network Authentication Required: The client needs to authenticate to gain network access, typically seen with captive portals in hotels, airports, and coffee shops.

Quick Reference Rules

When choosing a status code for your API response, these rules cover the majority of cases:

Successful GET or PUT: return 200
Successful POST that creates a resource: return 201 with a Location header
Successful DELETE: return 204 (no body needed)
Accepted but processing later: return 202
Bad request data or missing fields: return 400
Validation errors (correct syntax, wrong semantics): return 422
Not logged in: return 401
Logged in but lacks permissions: return 403
Resource does not exist: return 404
Rate limited: return 429 with Retry-After
Server broke: return 500 and investigate immediately

For more detailed API design guidance, read our API Status Code Best Practices article. To look up any specific code, use the HTTP Status Code Reference tool.

HTTP Status Code Cheat Sheet

How HTTP Status Codes Work

1xx Informational

2xx Success

3xx Redirection

4xx Client Error

5xx Server Error

Less Common but Important Codes

Quick Reference Rules

Further Reading

Related Articles

More DevPane Tools

HTTP Status Code Cheat Sheet

How HTTP Status Codes Work

1xx Informational

2xx Success

3xx Redirection

4xx Client Error

5xx Server Error

Less Common but Important Codes

Quick Reference Rules

Further Reading

Related Articles

More DevPane Tools