Complete guide to HTTP response status codes organized by category
HTTP status codes are grouped into five categories based on the first digit:
| Range | Category | Meaning | Common Codes |
|---|---|---|---|
| 1xx | Informational | Request received, continuing process | 100, 101 |
| 2xx | Success | Request successfully received, understood, and accepted | 200, 201, 204 |
| 3xx | Redirection | Further action needed to complete the request | 301, 302, 304 |
| 4xx | Client Error | Request contains bad syntax or cannot be fulfilled | 400, 401, 404 |
| 5xx | Server Error | Server failed to fulfill a valid request | 500, 502, 503 |
The following sections list all standard HTTP status codes organized by category. Each table provides a quick reference, while the most commonly encountered codes include detailed explanations with example request/response pairs to illustrate their practical usage.
Provisional responses indicating the request was received and the process is continuing.
| Code | Name | Description | RFC |
|---|---|---|---|
| 100 | Continue | Server has received request headers; client should send body | 9110 §15.2.1 |
| 101 | Switching Protocols | Server is switching protocols as requested (e.g., to WebSocket) | 9110 §15.2.2 |
| 103 | Early Hints | Server sends preliminary headers before final response | 8297 |
Tells the client to continue sending the request body. Used when client sends Expect: 100-continue header to check if server will accept a large request before sending it.
Use case: Large file uploads where you want server validation before transmitting
Server agrees to switch protocols as requested via the Upgrade header. Commonly used for WebSocket connections.
Use case: Upgrading HTTP connection to WebSocket
The request was successfully received, understood, and accepted.
| Code | Name | Description | RFC |
|---|---|---|---|
| 200 | OK | Standard success response; meaning varies by HTTP method | 9110 §15.3.1 |
| 201 | Created | Request fulfilled, new resource created | 9110 §15.3.2 |
| 202 | Accepted | Request accepted but not yet processed (async) | 9110 §15.3.3 |
| 204 | No Content | Success, but no body to return | 9110 §15.3.5 |
| 206 | Partial Content | Partial resource returned (range request) | 9110 §15.3.7 |
The most common success status. For GET, the resource is in the body. For POST, the result of the action is in the body.
Use case: Successful GET requests, form submissions, API calls
A new resource has been created. The Location header should contain the URI of the new resource.
Use case: POST request that creates a new record/resource
Request succeeded but there's nothing to return. The response must not include a body.
Use case: DELETE requests, PUT/PATCH that don't need to return data
Further action is needed to complete the request. Usually involves following a Location header.
| Code | Name | Description | RFC |
|---|---|---|---|
| 301 | Moved Permanently | Resource permanently moved; update bookmarks | 9110 §15.4.2 |
| 302 | Found | Resource temporarily at different URI | 9110 §15.4.3 |
| 303 | See Other | Redirect to GET another resource (after POST) | 9110 §15.4.4 |
| 304 | Not Modified | Resource unchanged; use cached version | 9110 §15.4.5 |
| 307 | Temporary Redirect | Temporary redirect, preserve HTTP method | 9110 §15.4.8 |
| 308 | Permanent Redirect | Permanent redirect, preserve HTTP method | 9110 §15.4.9 |
The resource has permanently moved to a new URL. Clients should update their links. Search engines will transfer SEO value to the new URL.
Use case: Site migrations, URL restructuring, enforcing canonical URLs
Used for caching. Client's cached version is still valid, no need to transfer the body again.
Use case: Conditional GET with If-None-Match or If-Modified-Since
Like 302, but guarantees the HTTP method won't change. A POST remains a POST after redirect.
Use case: Temporary maintenance redirects, preserving POST data
The request contains errors or cannot be fulfilled due to client-side issues.
| Code | Name | Description | RFC |
|---|---|---|---|
| 400 | Bad Request | Malformed syntax, invalid parameters | 9110 §15.5.1 |
| 401 | Unauthorized | Authentication required | 9110 §15.5.2 |
| 403 | Forbidden | Server refuses to authorize (even with auth) | 9110 §15.5.4 |
| 404 | Not Found | Resource does not exist | 9110 §15.5.5 |
| 405 | Method Not Allowed | HTTP method not supported for this resource | 9110 §15.5.6 |
| 409 | Conflict | Request conflicts with current resource state | 9110 §15.5.10 |
| 406 | Not Acceptable | Content negotiation failed (Accept headers) | 9110 §15.5.7 |
| 408 | Request Timeout | Client took too long to send request | 9110 §15.5.9 |
| 410 | Gone | Resource permanently deleted (no forwarding) | 9110 §15.5.11 |
| 411 | Length Required | Content-Length header required | 9110 §15.5.12 |
| 412 | Precondition Failed | Conditional request failed (If-Match, etc.) | 9110 §15.5.13 |
| 413 | Content Too Large | Request body exceeds server limit | 9110 §15.5.14 |
| 414 | URI Too Long | Request URI exceeds server limit | 9110 §15.5.15 |
| 415 | Unsupported Media Type | Content-Type not supported by server | 9110 §15.5.16 |
| 418 | I'm a Teapot | Server refuses to brew coffee (April Fools' joke) | 2324 §2.3.2 |
| 422 | Unprocessable Content | Syntax OK but semantically invalid | 9110 §15.5.21 |
| 428 | Precondition Required | Conditional request required (optimistic locking) | 6585 §3 |
| 429 | Too Many Requests | Rate limit exceeded | 6585 §4 |
| 451 | Unavailable For Legal Reasons | Blocked due to legal demands (censorship) | 7725 |
The server cannot process the request due to malformed syntax, invalid parameters, or bad framing. The response body should explain the problem.
Use case: Invalid JSON, missing required fields, malformed query strings
Authentication is required. Must include a WWW-Authenticate header indicating how to authenticate.
Use case: Missing or expired credentials, invalid API key
Server understood the request but refuses to authorize it. Authentication won't help—the user doesn't have permission.
Use case: Accessing admin resources as regular user, IP blocked
The requested resource could not be found. May be temporary or permanent (consider 410 for permanently gone).
Use case: Invalid URL, deleted resource, typo in path
Request syntax is correct, but the server can't process the contained instructions. Common for validation errors.
Use case: Email already exists, password too weak, business rule violation
Rate limit exceeded. Should include Retry-After header indicating when to retry.
Use case: API rate limiting, brute force protection
The server failed to fulfill a valid request. These errors are the server's fault.
| Code | Name | Description | RFC |
|---|---|---|---|
| 500 | Internal Server Error | Generic server error (catch-all) | 9110 §15.6.1 |
| 501 | Not Implemented | Server doesn't support the functionality | 9110 §15.6.2 |
| 502 | Bad Gateway | Invalid response from upstream server | 9110 §15.6.3 |
| 503 | Service Unavailable | Server temporarily unavailable (overload/maintenance) | 9110 §15.6.4 |
| 504 | Gateway Timeout | Upstream server didn't respond in time | 9110 §15.6.5 |
| 505 | HTTP Version Not Supported | Server doesn't support the HTTP version used | 9110 §15.6.6 |
| 507 | Insufficient Storage | Server cannot store the representation (WebDAV) | 4918 §11.5 |
| 508 | Loop Detected | Infinite loop detected processing request (WebDAV) | 5842 §7.2 |
| 511 | Network Authentication Required | Client needs to authenticate with network (captive portal) | 6585 §6 |
Generic error when the server encounters an unexpected condition. Avoid exposing internal details in production.
Use case: Unhandled exceptions, database errors, configuration issues
Server acting as gateway/proxy received an invalid response from upstream. Common with reverse proxies.
Use case: Backend server crashed, upstream returned malformed response
Server is temporarily unable to handle requests. Should include Retry-After header when possible.
Use case: Planned maintenance, server overloaded, dependency down
Choosing the right status code helps clients understand what happened and how to respond. This guide covers common scenarios for both traditional web applications and REST APIs.
These status codes apply across all types of web applications:
| Scenario | Status Code | Notes |
|---|---|---|
| Request succeeded, returning data | 200 OK | Most common success response |
| Created a new resource | 201 Created | Include Location header with new resource URL |
| Succeeded but nothing to return | 204 No Content | Good for DELETE or updates without response body |
| Resource moved permanently | 301 Moved Permanently | Search engines update their index |
| Resource moved temporarily | 307 Temporary Redirect | Preserves HTTP method (unlike 302) |
| Invalid data format from client | 400 Bad Request | Malformed JSON, missing parameters |
| Client needs to authenticate | 401 Unauthorized | Include WWW-Authenticate header |
| Authenticated but not authorized | 403 Forbidden | Valid credentials, insufficient permissions |
| Resource doesn't exist | 404 Not Found | Also used to hide existence of protected resources |
| Validation error (business rules) | 422 Unprocessable Content | Syntax OK but semantically invalid |
| Server error (your bug) | 500 Internal Server Error | Log details server-side, don't expose to client |
| Upstream service failed | 502 Bad Gateway | Backend or proxy received invalid response |
| Server overloaded or maintenance | 503 Service Unavailable | Include Retry-After header when possible |
REST APIs map HTTP methods to Create, Read, Update, and Delete operations. The status code should reflect both the operation type and its outcome.
| Scenario | Status | Notes |
|---|---|---|
| Single resource found | 200 OK | Return resource in body |
| Collection found (even if empty) | 200 OK | Return array, never 404 for empty collection |
| Resource not found | 404 Not Found | |
| User can't access this resource | 403 or 404 | Use 404 to hide existence |
| Client cache is still valid | 304 Not Modified | No body, client uses cached version |
| Scenario | Status | Notes |
|---|---|---|
| Resource created | 201 Created | Include Location header with new URL |
| Action completed, no resource created | 200 or 204 | For RPC-style endpoints |
| Processing asynchronously | 202 Accepted | Return status/polling URL in body |
| Duplicate resource | 409 Conflict | Resource with same identifier exists |
| Malformed request body | 400 Bad Request | JSON parse error, missing fields |
| Invalid data (business rules) | 422 Unprocessable | Valid JSON but fails validation |
| Scenario | Status | Notes |
|---|---|---|
| Update successful | 200 OK | Return updated resource |
| Update successful, no body | 204 No Content | When client doesn't need response |
| PUT created new resource | 201 Created | Only if client provides ID |
| Resource doesn't exist | 404 Not Found | PATCH always requires existing resource |
| Concurrent modification | 409 Conflict | ETag mismatch or version conflict |
| If-Match header missing | 428 Precondition Required | When optimistic locking is required |
| Precondition failed | 412 Precondition Failed | If-Match or If-Unmodified-Since failed |
| Wrong Content-Type for PATCH | 415 Unsupported Media Type | e.g., expected JSON Patch |
| Scenario | Status | Notes |
|---|---|---|
| Deleted successfully | 200 or 204 | 200 if returning deleted resource |
| Resource doesn't exist | 404 or 204 | 204 for idempotent behavior |
| Delete queued | 202 Accepted | For async deletion |
| Has dependencies | 409 Conflict | Can't delete due to references |
| Delete not allowed | 405 Method Not Allowed | Resource can never be deleted |
Consistent error responses help API consumers handle failures gracefully:
| Error Type | Status | When to Use |
|---|---|---|
| Syntax error | 400 Bad Request | JSON parse error, malformed request |
| Missing required field | 400 or 422 | 400 if structural, 422 if validation |
| Field validation failure | 422 Unprocessable | Email format, range checks, etc. |
| No credentials | 401 Unauthorized | No API key or token provided |
| Invalid credentials | 401 Unauthorized | Bad or expired token |
| Insufficient permissions | 403 Forbidden | Valid token but wrong role/scope |
| Rate limited | 429 Too Many Requests | Include Retry-After header |
| Payload too large | 413 Content Too Large | File upload exceeds limit |
| URL too long | 414 URI Too Long | Query string too large |
| Wrong Accept header | 406 Not Acceptable | Can't produce requested format |
Idempotent operations produce the same result regardless of how many times they're called. This is important for retry logic and reliability. GET, PUT, and DELETE should be idempotent; POST typically is not.
| Scenario | Idempotent Response | Strict Response |
|---|---|---|
| DELETE already-deleted resource | 204 No Content | 404 Not Found |
| PUT same data twice | 200 OK (same result each time) | |
| POST creating duplicate | 409 Conflict (POST is not idempotent) | |
The idempotent approach (returning success for already-deleted resources) simplifies client retry logic, since clients don't need to distinguish between "deleted now" and "already deleted."