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 |
| 422 | Unprocessable Content | Syntax OK but semantically invalid | 9110 §15.5.21 |
| 429 | Too Many Requests | Rate limit exceeded | 6585 §4 |
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 |
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 REST APIs.
| 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 |
| 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 |
REST APIs map HTTP methods to Create, Read, Update, and Delete operations.
| 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 |
| Scenario | Status | Notes |
|---|---|---|
| Resource created | 201 Created | Include Location header with new URL |
| Duplicate resource | 409 Conflict | Resource with same identifier exists |
| 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 |
| Resource doesn't exist | 404 Not Found | PATCH always requires existing resource |
| Scenario | Status | Notes |
|---|---|---|
| Deleted successfully | 200 or 204 | 200 if returning deleted resource |
| Resource doesn't exist | 404 or 204 | 204 for idempotent behavior |
| Has dependencies | 409 Conflict | Can't delete due to references |