HTTP Status Codes & Headers
Complete searchable reference for HTTP status codes (1xx–5xx) and common request/response headers — with descriptions, use cases and examples.
What are HTTP Status Codes and Headers?
HTTP status codes and headers are the two primary mechanisms servers use to communicate with clients beyond the response body. Status codes are three-digit numbers grouped into five classes — 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error) and 5xx (server error) — that tell the client at a glance whether its request succeeded and what to do next. Headers carry metadata about the request or response: authentication tokens, caching instructions, content format, security policies and more.
For DevOps and backend engineers, a solid working knowledge of HTTP headers is essential. Headers control caching at every layer of the stack — browser, CDN, reverse proxy and application. Security headers like Content-Security-Policy, Strict-Transport-Security and X-Frame-Options are often the first line of defence against common web attacks. Incorrect or missing headers cause subtle bugs that are hard to reproduce and easy to miss in code review.
When to Use This Reference
- API development: Look up the correct status code when implementing a new endpoint — especially for edge cases like partial success, rate limiting and async operations.
- Security hardening: Verify which security headers your server is missing by comparing against the reference, then add them to your Nginx, Apache or application configuration.
- CDN and cache tuning: Understand
Cache-Control,ETag,VaryandAgesemantics when diagnosing stale content or over-caching at the edge. - Debugging HTTP issues: Use this as a lookup when a client reports an unexpected status code — understand exactly what that code means and what the correct response should have been.
- CORS troubleshooting: Reference the exact
Access-Control-Allow-*headers needed for cross-origin requests to work correctly.
How It Works
The reference covers all status codes defined in RFC 7231 and subsequent RFCs, plus widely-used de facto standards like 429 Too Many Requests and 451 Unavailable for Legal Reasons. Headers are split into request headers (sent by the client) and response headers (sent by the server). Each entry includes the standard name, a plain-English description, the relevant RFC, common values and practical notes on when and how to use it in production systems.
Frequently Asked Questions
What are the most important HTTP headers for API security?
The five security headers every HTTP response should include are: Strict-Transport-Security (forces all future requests to use HTTPS), Content-Security-Policy (restricts which scripts and resources the browser can load, preventing XSS), X-Content-Type-Options: nosniff (prevents browsers from MIME-sniffing responses), X-Frame-Options: DENY (blocks clickjacking by preventing your page from being embedded in an iframe), and Referrer-Policy: strict-origin-when-cross-origin (limits referer header leakage). For pure JSON APIs, also set Content-Type: application/json on every response and reject requests with mismatched Content-Type headers at the middleware level.
How does Cache-Control work, and when should I use no-cache vs no-store?
Cache-Control: no-cache means the cached response must be revalidated with the server before being served — the response is cached but always checked for freshness first. Cache-Control: no-store means the response must never be written to any cache at all — use this for responses containing sensitive data like banking information or personal health records. Use max-age=N to allow caching for N seconds without revalidation — appropriate for static assets with content hashes in the filename. When both Cache-Control and the older Expires header are present, Cache-Control takes precedence in all modern clients and CDNs.
What is the difference between 401 and 403, and when should I return 404 instead?
Return 401 Unauthorized when the request carries no authentication credentials or the credentials are invalid — include a WWW-Authenticate header so the client knows how to authenticate. Return 403 Forbidden when the caller is authenticated but lacks permission for the specific resource. Return 404 Not Found instead of 403 as a deliberate security choice when you want to prevent an unauthenticated caller from discovering that a resource exists at all — this is common for admin endpoints, private user data and sensitive configuration paths. The trade-off is slightly more confusing debugging for legitimate developers, so document this behaviour in your API spec.