HTTP Status Codes Cheat Sheet: Every Code Explained
What Are HTTP Status Codes?
Every time your browser, mobile app, or API client makes an HTTP request, the server responds with a three-digit status code. This code tells the client whether the request succeeded, failed, or needs additional action. Understanding HTTP status codes is essential for debugging APIs, building web applications, and diagnosing server issues.
This HTTP status codes cheat sheet covers every standard code across all five categories, with explanations and common causes for the ones you will encounter most often.
1xx — Informational
These codes indicate that the server has received the request and is continuing to process it. You rarely encounter these directly.
| Code | Name | Meaning |
|---|---|---|
| 100 | Continue | The server received the request headers. The client should proceed with the body. |
| 101 | Switching Protocols | The server is switching to the protocol requested by the client (e.g., WebSocket upgrade). |
| 102 | Processing | The server is processing the request but has no response yet. Prevents client timeout on long operations. |
| 103 | Early Hints | The server sends preliminary response headers (like Link headers for preloading) before the final response. |
2xx — Success
The request was received, understood, and processed successfully.
| Code | Name | Meaning |
|---|---|---|
| 200 | OK | Standard success response. The response body contains the requested resource. |
| 201 | Created | A new resource was created successfully. Common for POST requests. The response typically includes a Location header. |
| 202 | Accepted | The request was accepted for processing but is not complete yet. Used for asynchronous operations. |
| 204 | No Content | Success, but there is no response body. Common for DELETE requests or updates that do not return data. |
| 206 | Partial Content | The server is delivering part of the resource due to a range header sent by the client. Used for resumable downloads and video streaming. |
Common 2xx Notes
- 200 vs 201: Use 201 when a POST request creates a new resource. Use 200 for everything else that succeeds.
- 204 vs 200 with empty body: Use 204 when there is genuinely no content to return. It tells the client not to expect a body.
3xx — Redirection
The client must take additional action to complete the request, usually by following a URL in the Location header.
| Code | Name | Meaning |
|---|---|---|
| 301 | Moved Permanently | The resource has permanently moved to a new URL. Browsers cache this redirect. Search engines transfer link equity. |
| 302 | Found | Temporary redirect. The resource is temporarily at a different URL. Browsers do not cache by default. |
| 303 | See Other | Redirect to a different resource using GET. Used after a POST to redirect the client to a results page. |
| 304 | Not Modified | The resource has not changed since the client’s last request (based on ETag or Last-Modified). The client should use its cached version. |
| 307 | Temporary Redirect | Like 302, but the request method must not change. A POST request stays a POST. |
| 308 | Permanent Redirect | Like 301, but the request method must not change. A POST request stays a POST. |
Common 3xx Notes
- 301 vs 308: Use 301 for GET redirects (most common). Use 308 when you need to preserve the POST method.
- 302 vs 307: Same distinction. 302 allows method change; 307 preserves the original method.
4xx — Client Error
The request has a problem on the client side. The server understood the request but will not process it.
| Code | Name | Meaning |
|---|---|---|
| 400 | Bad Request | The request is malformed. Missing required fields, invalid JSON, or incorrect data types. |
| 401 | Unauthorized | Authentication is required but was not provided or is invalid. Despite the name, this is about authentication, not authorization. |
| 403 | Forbidden | The server understood the request but refuses to authorize it. The client is authenticated but does not have permission. |
| 404 | Not Found | The requested resource does not exist. The most recognized HTTP status code. |
| 405 | Method Not Allowed | The HTTP method (GET, POST, PUT, etc.) is not supported for this endpoint. |
| 408 | Request Timeout | The client took too long to send the request. |
| 409 | Conflict | The request conflicts with the current state of the resource. Common when trying to create a resource that already exists. |
| 413 | Content Too Large | The request body exceeds the server’s size limit. |
| 415 | Unsupported Media Type | The server does not support the request’s Content-Type. Sending XML to an endpoint that expects JSON, for example. |
| 422 | Unprocessable Content | The request is syntactically valid but semantically incorrect. The JSON is valid, but a field value fails validation (e.g., negative age). |
| 429 | Too Many Requests | Rate limiting. The client has sent too many requests in a given time period. Check the Retry-After header for when to try again. |
Common 4xx Debugging Tips
- 400: Check request body formatting. Validate your JSON with a JSON Formatter before sending.
- 401 vs 403: 401 means “who are you?” (missing/invalid credentials). 403 means “I know who you are, but you cannot access this” (insufficient permissions).
- 404: Verify the URL path, including trailing slashes. Check if the resource was deleted. Use the URL Encoder if your path contains special characters.
- 429: Implement exponential backoff. Respect the rate limit headers.
5xx — Server Error
The server failed to fulfill a valid request. These are server-side problems, not client mistakes.
| Code | Name | Meaning |
|---|---|---|
| 500 | Internal Server Error | A generic server error. Something went wrong, but the server cannot be more specific. |
| 501 | Not Implemented | The server does not support the functionality required to fulfill the request. |
| 502 | Bad Gateway | The server, acting as a proxy or gateway, received an invalid response from the upstream server. |
| 503 | Service Unavailable | The server is temporarily unable to handle the request. Usually due to maintenance or overload. Check the Retry-After header. |
| 504 | Gateway Timeout | The server, acting as a proxy, did not receive a timely response from the upstream server. |
Common 5xx Debugging Tips
- 500: Check server logs. This is the catch-all error and almost always indicates a bug in your application code.
- 502: Check if your upstream service (application server, microservice) is running and healthy. Common with Nginx or load balancers when the backend is down.
- 503: Check server capacity and whether deployment or maintenance is in progress. Often resolves itself.
- 504: Check the upstream service for slow responses. Increase timeout settings if the operation legitimately takes long.
Quick Reference Table
| Range | Category | Client Action |
|---|---|---|
| 1xx | Informational | Continue waiting |
| 2xx | Success | Process the response |
| 3xx | Redirection | Follow the Location header |
| 4xx | Client Error | Fix the request |
| 5xx | Server Error | Retry later or check server logs |
Status Codes in API Design
If you are building an API, using the right status codes improves developer experience:
- Return 201 for resource creation, not 200
- Return 204 for successful deletes with no response body
- Return 422 for validation errors, not 400 (422 is more specific)
- Return 409 for duplicate resource conflicts
- Return 429 with a
Retry-Afterheader for rate limiting - Never return 200 with an error message in the body — use proper 4xx/5xx codes
Conclusion
This HTTP status codes cheat sheet covers the codes you will encounter in daily development. Bookmark it for quick reference when debugging API calls or designing your own endpoints.
For related debugging tools, use the JSON Formatter to validate API response bodies, the URL Encoder to debug URL issues, and the Diff Checker to compare API responses side by side.