HTTP Status Codes Complete Interactive Reference — Every Code Explained

HTTP Status Codes — The Complete Guide for Developers

HTTP status codes are three-digit numbers returned by a web server in response to every HTTP request. They tell the client — a browser, API client, or application — whether the request succeeded, failed, was redirected, or encountered an error. Understanding status codes is foundational for web development, REST API design, debugging, SEO and infrastructure monitoring.

Status codes are standardised in RFC 9110 (HTTP Semantics, 2022), which supersedes RFC 7231. The first digit determines the class of response. Every subsequent digit adds specificity within that class.

The 10 Most Important HTTP Status Codes Every Developer Must Know

HTTP 200 OK — the baseline

200 is the default success response. For GET requests it means the requested resource is in the body. For POST it means the action was completed and the result is in the body. Never return 200 with an error body — this is a common anti-pattern in older APIs that breaks monitoring and client error handling.

HTTP 201 Created — resource born

Return 201 after a POST creates a new resource. Always include a Location: /api/resource/id header pointing to the new resource. Omitting the Location header is a spec violation. If creation is asynchronous (queued), use 202 Accepted instead and point the Location header to a status endpoint.

HTTP 204 No Content — success with nothing to say

Return 204 for successful DELETE operations and PUT/PATCH operations where you do not need to return the updated resource. The response must not include a body — some clients break if you send a body with 204. Also used for CORS preflight responses.

HTTP 400 vs 422 — the malformed vs invalid distinction

Use 400 Bad Request when the request itself is malformed: unparseable JSON, missing Content-Type header, invalid URL structure. Use 422 Unprocessable Content when the request is syntactically valid but semantically wrong: email format invalid, age must be positive, required relationship missing. Return RFC 9457 Problem Details format for structured error responses.

HTTP 401 vs 403 — the authentication vs authorisation distinction

This is the most commonly confused pair in the entire status code spec. 401 Unauthorized means the request lacks valid authentication — the server does not know who you are. Always include WWW-Authenticate header. 403 Forbidden means the client is authenticated but lacks permission — the server knows who you are but refuses access. Re-authenticating will not help a 403. A third option: return 404 instead of 403 when you want to hide that a resource exists at all (security through obscurity, sometimes appropriate).

HTTP 404 vs 410 — gone vs gone forever

404 Not Found is ambiguous — the resource may be temporarily or permanently unavailable. Google typically deindexes a 404 after several crawl cycles over days or weeks. 410 Gone is definitive — the resource is permanently deleted. Google deindexes 410 within one or two crawl cycles. For deleted content you want removed from search results quickly (cancelled accounts, removed products, deprecated endpoints), use 410 deliberately.

HTTP 429 Too Many Requests — rate limiting done right

Always include Retry-After (seconds or HTTP date) so clients know when to retry. Also include X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers so clients can implement proactive throttling rather than reacting to 429s. Implement exponential backoff in clients — naive retry loops after 429 make the rate limiting problem worse.

HTTP 500 Internal Server Error — the critical rule

Never expose internal error details in a 500 response — not stack traces, not file paths, not database connection strings, not error IDs that enumerate internal systems. Log the full error internally with a correlation ID, then return a generic message to the client. Include the correlation ID in the response so users can report it: {"error":"Something went wrong","reference":"ERR-abc123"}. 500s are safe to retry with exponential backoff.

HTTP 503 Service Unavailable — maintenance done right

Always include Retry-After so load balancers and API clients know when to try again. Return an HTML error page for browser requests and JSON for API clients (check the Accept header). Googlebot reduces its crawl rate for sites returning 503. If 503s persist for more than a few days, Google may begin removing affected URLs from search results.

HTTP 301 vs 302 redirects — the SEO difference

301 Moved Permanently passes PageRank (link equity) to the destination URL. Search engines update their index to the new URL. 302 Found does not pass PageRank — Google indexes the original URL, not the destination. Use 301 for all permanent URL changes: HTTP to HTTPS migrations, domain changes, www to non-www. Use 302 for temporary redirects: A/B testing, login redirects, maintenance pages. Avoid redirect chains — go directly to the final destination.

Choosing the Right Status Code for REST APIs — Practical Decision Guide

GET request outcomes

POST request outcomes

DELETE request outcomes

How HTTP Status Codes Affect SEO & Googlebot Crawling

Every status code your server returns to Googlebot directly affects crawl budget, indexing, link equity and how quickly changes take effect in search results.

Which HTTP Status Codes Are Safe to Retry?

A well-designed HTTP client should implement selective retry logic — not all status codes are safe to retry automatically.

Implement exponential backoff: start with 1 second, double each retry, add random jitter, cap at 60–120 seconds. After 3–5 retries, fail gracefully and notify the user.

LazyTools vs Other HTTP Status Code References

HTTP Status Code FAQ

More Free Developer Tools