All HTTP status codes — 1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error
HTTP Status Codes Reference documents all standard HTTP status codes with their meaning, when to use them, and common mistakes. Browse by category (1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error), or search by code number or name. Each entry includes the RFC definition, typical use case, and what the client should do when receiving it.
HTTP status codes are 3-digit integers in the response that tell the client what happened. The first digit indicates the class: 1xx (informational -- request received, continuing), 2xx (success -- request received, understood, and accepted), 3xx (redirection -- further action needed), 4xx (client error -- the request contains bad syntax or cannot be fulfilled), 5xx (server error -- the server failed to fulfill an apparently valid request).
Common codes: 200 OK, 201 Created (POST success), 204 No Content (DELETE/PUT with empty body), 301 Moved Permanently (permanent redirect), 302 Found (temporary redirect), 304 Not Modified (cached), 400 Bad Request (invalid input), 401 Unauthorized (authentication required), 403 Forbidden (insufficient permissions), 404 Not Found, 422 Unprocessable Entity (validation failure), 429 Too Many Requests (rate limit), 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.
Successful POST
Result: 201 Created + Location: /users/42 header -> new resource created
Validation error
Result: 422 Unprocessable Entity + JSON error body -> client sent valid JSON but semantic errors
Rate limited
Result: 429 Too Many Requests + Retry-After: 60 header -> try again in 60 seconds
What is the difference between 401 and 403?
401 Unauthorized: authentication is required and has failed or not been provided. Despite the name, it means authentication is missing or wrong. The response should include a WWW-Authenticate header. Client action: prompt the user to log in. 403 Forbidden: the client is authenticated but lacks permission to access the resource. The server understood the request but refuses to authorize it. Client action: show 'access denied'. Rule of thumb: 401 = who are you? 403 = I know who you are, but you cannot do this.
When should I return 400 vs 422?
400 Bad Request: the request syntax is malformed -- invalid JSON, missing required headers, or the request cannot be parsed. Example: sending non-JSON to a JSON-only endpoint, or a Content-Type mismatch. 422 Unprocessable Entity: the request is syntactically valid but semantically invalid -- the JSON is valid but business logic validation failed. Example: required field missing in a valid JSON body, invalid email format, start date after end date. Many REST APIs use 400 for all validation errors for simplicity -- 422 is semantically more correct per RFC 9110.
What is the difference between 301 and 302 redirects?
301 Moved Permanently: the resource has permanently moved to the new URL. Browsers and search engines cache this indefinitely. Future requests go directly to the new URL. Use for: permanent URL changes, domain migrations, HTTP to HTTPS redirects. 302 Found (temporary redirect): the resource is temporarily at a different URL. Browsers do not cache this permanently. Use for: maintenance redirects, A/B testing, login redirects. SEO impact: 301 passes link equity (PageRank) to the new URL; 302 does not. 308 Permanent Redirect and 307 Temporary Redirect are similar but preserve the HTTP method (do not change POST to GET).
What does 429 Too Many Requests mean and how should I handle it?
429 Too Many Requests indicates the client has exceeded a rate limit. The response should include a Retry-After header (seconds until the limit resets) or X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset headers (custom convention). Client handling: read the Retry-After header and wait before retrying. Implement exponential backoff with jitter for retries. Server implementation: track requests per API key, IP, or user using a sliding window or token bucket algorithm. Redis is commonly used for distributed rate limiting.
When should I use 204 No Content?
204 No Content means the request succeeded but there is no response body. Use for: DELETE requests that succeed (resource deleted, nothing to return), PUT/PATCH when you do not want to return the updated resource, logout endpoints, bulk operations that succeed silently. Do not use 204 for GET requests -- GET should return 200 with the resource or 404 if not found. Some REST APIs return 200 with an empty body or {success: true} instead of 204 -- both are valid but 204 is semantically cleaner for operations that produce no output.