When should I use 301 vs 302 vs 307 vs 308 redirects?

301 Moved Permanently — permanent redirect for GET requests (SEO page moves). Browsers may change POST to GET. 302 Found — temporary redirect, browsers may change POST to GET. 307 Temporary Redirect — temporary redirect that preserves the HTTP method (POST stays POST). 308 Permanent Redirect — permanent redirect that preserves the HTTP method. For API endpoint moves, use 307 (temporary) or 308 (permanent). For website page moves, 301 is standard. For Post-Redirect-Get patterns, use 303 See Other.

Should I use 400 or 422 for validation errors?

422 Unprocessable Entity is the de facto standard for validation errors in REST APIs. It means the server understands the content type and the JSON is syntactically valid, but the data fails semantic validation (e.g., email format is wrong, age is negative). 400 Bad Request is more generic and should be used when the request itself is malformed — invalid JSON, missing required headers, or unparseable request body. Most modern frameworks (Rails, Laravel, FastAPI) use 422 for field-level validation errors.

What HTTP status code should a REST API return for a successful DELETE?

The most common responses for a successful DELETE are 204 No Content (preferred — no body, the resource is gone), 200 OK (with a response body containing the deleted resource or a confirmation message), and 202 Accepted (if the deletion is asynchronous and hasn't completed yet). 204 is the cleanest choice because there's typically nothing meaningful to return after a deletion.

What do Cloudflare's 520–527 status codes mean?

These are Cloudflare-specific error codes that map origin server problems into HTTP responses. 520: unknown error from origin. 521: origin server refused the connection (web server down). 522: connection to origin timed out. 523: origin is unreachable (DNS/routing issue). 524: origin didn't respond within timeout (100s default). 525: SSL handshake with origin failed. 526: origin SSL certificate is invalid. 527: Railgun connection error. These codes help you diagnose problems between Cloudflare's edge and your origin server.

Free HTTP Status Codes Cheat Sheet Online — 120+ Response Codes & REST API Reference

Q: What is the difference between 502 Bad Gateway and 504 Gateway Timeout?

502 Bad Gateway means the upstream server returned an invalid response — it crashed mid-response, sent malformed HTTP, or returned something the proxy couldn't parse. 504 Gateway Timeout means the upstream server didn't respond at all within the configured timeout period. 502 = broken response received, 504 = no response received (timeout). Both indicate problems with the backend server, not the client.

Every time you open a web page, submit a form, or call a REST API, a three-digit number travels back through the wire. That number — the HTTP status code — is the server's universal language for telling the client what happened. Was the request successful? Is the resource gone? Is the server on fire? These codes are the control panel lights of the web, and reading them fluently separates senior engineers from everyone else. Our free interactive HTTP Status Codes Cheat Sheet gives you instant access to 120 response codes across 10 categories, with real-time search, one-click copy, and a Mission Control Room aesthetic inspired by spacecraft command centers and system monitoring dashboards. No signup. No server. 100% client-side.

Why Every Developer Must Master HTTP Status Codes

HTTP status codes are the shared vocabulary of the web. When you see 404, you know immediately: the resource wasn't found. When your API returns 429, you know you're being rate-limited. When production monitoring shows a spike in 502s, you know the upstream server is failing. These three-digit numbers compress an entire diagnostic story into a single integer — but only if you know how to read them. A 400 and a 422 may both mean "client error," but they tell very different stories about what went wrong. A 301 and a 308 both redirect permanently, but only one preserves the HTTP method. Mastering the full HTTP status code list transforms debugging from guesswork into a systematic process.

Our cheat sheet organizes 120 HTTP status codes into 10 focused categories: 1xx Informational (the handshake codes — 100 Continue, 101 Switching Protocols for WebSocket upgrades, 102 Processing, 103 Early Hints for performance optimization), 2xx Success (200 OK through 206 Partial Content, plus the critical 200 vs 201 vs 204 decision guide), 3xx Redirection (every redirect variant from 301 Moved Permanently to 308 Permanent Redirect, with method-preservation comparison tables), 4xx Client Error — Request (400–408, covering authentication, authorization, validation), 4xx Client Error — Content (409–417, covering conflicts, preconditions, payload limits), 4xx Client Error — Advanced (418 I'm a Teapot through 429 Too Many Requests with rate limiting strategies), 4xx Client Error — Headers & Legal (431 Request Header Fields Too Large, 451 Unavailable For Legal Reasons, plus nginx/IIS/Laravel custom codes), 5xx Server Error — Core (500–505, the infrastructure errors every on-call engineer must recognize instantly), 5xx Server Error — Extended (506–511 plus error logging and monitoring best practices), and CDN & Reverse Proxy Codes (Cloudflare 520–527, AWS ELB 561, Varnish 503 Guru Meditation, and frontend-vs-backend status mapping). Each entry includes the status code, when it appears, how to debug it, and what action to take next.

1xx Informational — The Handshake Codes

1xx status codes are provisional responses — the server is saying "I'm working on it, keep going" or "let's switch protocols." Our 1xx Informational category covers: 100 Continue (the server received the request headers and the client should send the body — the Expect: 100-continue handshake that prevents uploading large files only to get a 401), 101 Switching Protocols (the critical WebSocket upgrade handshake — the server agrees to switch from HTTP to ws://, used by every real-time chat, live dashboard, and collaborative editing tool), 102 Processing (WebDAV — the server is working on a long request, preventing client-side timeout), 103 Early Hints (the performance optimization code — server sends Link headers for preloading critical CSS/JS/fonts before the full response, shaving 200–1000ms off Largest Contentful Paint), the complete Expect: 100-continue handshake flow (client sends headers first, waits for 100, then sends body — saving bandwidth when requests would be rejected), the WebSocket 101 upgrade flow (with Sec-WebSocket-Key/Accept exchange), 101 vs 426 Upgrade Required (101 accepts the upgrade, 426 demands it), 103 preload via Link header (parallelizing resource fetching with server processing), when 1xx responses are skipped (HTTP/1.0 clients and some proxies don't support them), HTTP/2 1xx handling differences (101 is forbidden in h2, use CONNECT instead), and proxy 1xx forwarding configuration (Nginx proxy_intercept_errors, HAProxy http-buffer-request).

2xx Success — When Things Go Right

Success codes seem straightforward, but choosing the wrong one creates confusion. Our 2xx Success category covers: 200 OK (the generic success — meaning depends on method: GET returns the resource, POST returns a result, PUT returns the updated resource), 201 Created (a new resource was created — must include a Location header pointing to the new URL, the cornerstone of RESTful resource creation), 202 Accepted (request is queued for async processing — return immediately with a status URL for polling, used for report generation, email sending, batch jobs), 203 Non-Authoritative Information (response came from a cache or third-party, not the origin — rarely used in practice), 204 No Content (success with no body — the browser stays on the same page, standard for DELETE operations and fire-and-forget actions), 205 Reset Content (like 204 but the browser should clear form inputs — useful after form submissions), 206 Partial Content (returning a byte range of a resource — enables resumable downloads and video seeking with Range and Content-Range headers), the 200 vs 201 vs 204 decision guide (when to use each, with the Location header rule for 201), the 201 Location header pattern (how to construct the URL of a newly created resource), the 206 Content-Range format (bytes start-end/total, inclusive indices), 206 multipart/byteranges (returning multiple ranges in a single response with boundary-separated parts), and the 202 async processing pattern (the standard way to handle long-running API operations: accept immediately, process in background, poll or webhook for completion).

3xx Redirection — The Traffic Control Tower

Redirection codes are simple in concept but subtle in behavior — method preservation, caching, and SEO implications vary dramatically between codes. Our 3xx Redirection category covers: 300 Multiple Choices (the resource has multiple representations — rarely used, content negotiation via Accept header is preferred), 301 Moved Permanently (permanent redirect for SEO page moves — search engines transfer ranking, browsers cache it, but POST may change to GET), 302 Found (temporary redirect — search engines keep the original URL, but browsers may change POST to GET), 303 See Other (the canonical Post-Redirect-Get pattern — always changes to GET regardless of original method, prevents duplicate form submissions on refresh), 304 Not Modified (the bandwidth saver — resource hasn't changed, use your cached copy, works with ETag/If-None-Match and If-Modified-Since, one of the most common 3xx codes in production), 305 Use Proxy (deprecated — security risk, do not use), 306 Switch Proxy (reserved, never implemented), 307 Temporary Redirect (preserves the HTTP method — POST stays POST, essential for temporary API endpoint moves), 308 Permanent Redirect (permanent and preserves the method — what 301 should have been for non-GET requests), the 301 vs 308 comparison (when method preservation matters vs when it doesn't), the 302 vs 307 comparison (temporary redirects with and without method preservation), and redirect chain debugging (using curl -L -v to trace each hop, browser limits of ~20 redirects, avoiding chains longer than 5 hops).

4xx Client Error — Request Problems

Client errors mean the request itself has a problem — and the fix is on the client side. Our 4xx Client Error — Request category covers the fundamental client error codes: 400 Bad Request (the generic catch-all for malformed requests — always return a descriptive body with field-level error details), 401 Unauthorized (authentication required — must include WWW-Authenticate header, means "who are you?" not "you can't do that"), 402 Payment Required (reserved for digital payments — can be repurposed for SaaS subscription upgrade prompts), 403 Forbidden (authenticated but not authorized — "I know who you are but you can't access this"), 404 Not Found (the most recognized HTTP status code — for sensitive resources, return 404 even if the resource exists to avoid information leakage), 405 Method Not Allowed (the HTTP method isn't supported for this endpoint — must include Allow header listing valid methods), 406 Not Acceptable (content negotiation failed — server can't produce any format the client accepts), 407 Proxy Authentication Required (like 401 but for the proxy — used in corporate environments), 408 Request Timeout (server timed out waiting for the client to complete its request — the client was too slow sending the body), the critical 401 vs 403 distinction (authentication vs authorization — one of the most common API design mistakes), the WWW-Authenticate header specification (Basic, Bearer, Digest, Negotiate, and custom schemes), and 400 validation patterns (structured error responses with per-field details for client-side form validation mapping).

4xx Client Error — Content & Preconditions

Content-related 4xx errors deal with request body issues, version conflicts, and size limits. Our 4xx Client Error — Content category covers: 409 Conflict (the request conflicts with current server state — essential for optimistic concurrency with If-Match/ETag), 410 Gone (resource was permanently deleted and won't come back — search engines remove the URL faster than 404, use for expired content and deleted accounts), 411 Length Required (server needs a Content-Length header — common with upload endpoints), 412 Precondition Failed (a conditional header like If-Match evaluated to false — someone else modified the resource since you read it, prevents lost updates), 413 Payload Too Large (request body exceeds the server's maximum — check Content-Length before sending large files, common server limits: Nginx 1MB, Express 100KB, Cloudflare 100MB), 414 URI Too Long (the URL is too long — typically from long query strings, fix by using POST with a body instead), 415 Unsupported Media Type (the Content-Type isn't accepted — common when sending XML to a JSON-only API), 416 Range Not Satisfiable (the requested byte range is outside the file's size — server returns Content-Range: bytes */actual-size), 417 Expectation Failed (server can't meet the Expect header requirements — rare on modern servers), the 410 vs 404 distinction (temporary absence vs permanent removal — use 410 to actively tell clients to stop requesting), the 412 If-Match/If-None-Match headers (optimistic locking vs caching — If-Match prevents lost updates, If-None-Match enables efficient caching), and 413 max request size configuration guide (Nginx client_max_body_size, Express body-parser limit, PHP upload_max_filesize, Cloudflare plans).

4xx Client Error — Advanced Validation & Rate Limiting

Advanced 4xx codes handle validation, rate limiting, concurrency, and protocol requirements. Our 4xx Client Error — Advanced category covers: 418 I'm a Teapot (RFC 2324 April Fools' joke — the server refuses to brew coffee because it's a teapot, the HTCPCP protocol Easter egg), 421 Misdirected Request (HTTP/2 connection reuse problem — the server can't serve this host on this connection), 422 Unprocessable Entity (the de facto standard for validation errors in REST APIs — JSON parses but the data doesn't make semantic sense, used by Rails, Laravel, FastAPI), 423 Locked (WebDAV — the resource is locked for editing, used in collaborative document systems), 424 Failed Dependency (WebDAV — a dependent operation failed, common in multi-step processes), 425 Too Early (TLS 1.3 0-RTT replay protection — server refuses to process potentially replayed early data), 426 Upgrade Required (server demands a protocol upgrade — different from 101 which accepts an upgrade, 426 requires one), 428 Precondition Required (server requires conditional requests — client must include If-Match to prevent lost updates), 429 Too Many Requests (rate limiting — must include Retry-After header, pair with X-RateLimit-Limit/Remaining/Reset headers), the complete 422 REST API validation pattern (per-field error messages mapped to form fields, internationalization-ready), the 429 Retry-After header specification (seconds or HTTP-date, exponential backoff with jitter), and 429 rate limiting strategies (fixed window vs sliding window log vs token bucket vs leaky bucket — choose based on traffic pattern).

4xx Client Error — Headers, Legal Codes & Server-Specific

This category covers oversized headers, legal takedowns, and server-specific client error codes from nginx, IIS, and Laravel. Our 4xx Client Error — Headers & Legal category covers: 431 Request Header Fields Too Large (total header size exceeds server limit — common with too many cookies or large tokens, Nginx: large_client_header_buffers), 451 Unavailable For Legal Reasons (RFC 7725 — content blocked by court order, copyright takedown, or government regulation, reference to Ray Bradbury's Fahrenheit 451), 499 Client Closed Request (nginx-specific — the client disconnected before the server finished processing, not a server error), 444 No Response (nginx-specific — close connection without any response, used as an anti-abuse measure), nginx SSL/TLS errors: 494 (request header too large), 495 (client SSL certificate error), 496 (client didn't provide required SSL certificate for mTLS), 497 (plain HTTP sent to HTTPS port), 498 Token Expired (nginx auth modules — the access token exists but has expired, client should refresh), 419 Page Expired (Laravel — CSRF token expired, user left the form open too long), 420 Enhance Your Calm (Twitter API v1 — rate limiting with attitude, the most creative HTTP status code in history), 440 Login Time-out (IIS — session expired due to inactivity), 449 Retry With (Microsoft Exchange/SharePoint — retry after performing a specific action), CORS and 4xx errors (browser blocks cross-origin responses before JavaScript sees the status code — check Access-Control headers), and debugging 4xx with curl -v (seeing the full request/response including all headers and error bodies).

5xx Server Error — Core Infrastructure Failures

Server errors mean the problem is on the backend — and on-call engineers need to diagnose them fast. Our 5xx Server Error — Core category covers: 500 Internal Server Error (the generic catch-all — always log the full stack trace server-side, never expose internals to clients, return a request ID for support correlation), 501 Not Implemented (server recognizes the HTTP method but hasn't implemented it — different from 405 which means the method isn't allowed on this resource), 502 Bad Gateway (upstream server returned an invalid response — crashed mid-response, sent garbage, or malformed HTTP, check whether the backend process is running), 503 Service Unavailable (server is temporarily down — overload, maintenance, or restarting, always include Retry-After header), 504 Gateway Timeout (upstream didn't respond within the timeout — backend is too slow or hung, common with Nginx → Node.js or AWS ALB → EC2), 505 HTTP Version Not Supported (server rejects the HTTP protocol version — extremely rare on modern servers), the critical 502 vs 504 distinction (502 = bad response received, 504 = no response received, root causes and debugging approaches differ), 503 Retry-After best practice (planned maintenance vs unexpected downtime — different Retry-After strategies), the dangers of 500 as a generic catch-all (losing debugging information, why specific codes like 502/503/504 produce better monitoring), 501 vs 405 comparison (server-level vs resource-level — 501 means the entire server doesn't implement the method, 405 means this specific endpoint doesn't), 500 debugging with correlation IDs (X-Request-ID middleware, structured logging, tracing requests across microservices), and custom 5xx error page design (user-friendly messages with retry buttons, never exposing stack traces or internal IPs).

5xx Server Error — Extended Failures & Monitoring

Extended 5xx codes cover WebDAV storage issues, captive portals, and the monitoring infrastructure needed to catch server errors before users do. Our 5xx Server Error — Extended category covers: 506 Variant Also Negotiates (server's content negotiation has a circular reference — configuration error, not a client problem), 507 Insufficient Storage (WebDAV — server is out of disk space or reached a storage quota, common in containerized environments), 508 Loop Detected (WebDAV — infinite loop detected during recursive operations, such as symbolic link loops or redirect loops), 510 Not Extended (RFC 2774 — the request requires extensions the client didn't specify, framework never widely adopted), 511 Network Authentication Required (captive portal detection — WiFi login pages, hotel internet, used by macOS/Windows/Android to show the login window), 506 negotiation misconfiguration debugging (Apache type-map circular references and how to fix them), 507 disk full scenarios (Docker ephemeral storage, Kubernetes node disk pressure and pod eviction, log rotation and temp file cleanup), 508 infinite loop prevention (Nginx redirect loop detection, symlink loops in filesystems, how servers terminate recursive operations), 510 extension framework history (why RFC 2774 failed to gain adoption), 511 captive portal detection mechanics (how macOS calls captive.apple.com, Windows calls msftconnecttest.com, Android calls gstatic.com/generate_204), error logging best practices (structured JSON logging with timestamp, request ID, URL, method, user ID, stack trace — queryable by status code and endpoint), and 5xx monitoring & alerting thresholds (warn at 0.5% error rate for 5 minutes, critical at 1%, pager at 5% — always correlate with deployments and traffic spikes using Grafana, Datadog, or CloudWatch).

CDN & Reverse Proxy Status Codes — The Edge Layer

CDN-specific codes translate connection-level problems into HTTP responses that clients can handle. Our CDN & Reverse Proxy Codes category covers the Cloudflare 52x series and other proxy-specific codes: 520 Unknown Error (Cloudflare — origin returned an empty or unexpected response, check origin server logs), 521 Web Server Down (Cloudflare — origin refused the TCP connection, server process stopped or firewall blocking Cloudflare IPs), 522 Connection Timed Out (Cloudflare — TCP connection to origin timed out, server overloaded or network congestion), 523 Origin Unreachable (Cloudflare — DNS resolution or IP routing to origin failed, check DNS propagation), 524 A Timeout Occurred (Cloudflare — origin didn't send HTTP response within 100 seconds, make slow operations async with 202 Accepted), 525 SSL Handshake Failed (Cloudflare — TLS handshake with origin failed, certificate expired or untrusted), 526 Invalid SSL Certificate (Cloudflare — origin SSL cert validation failed, hostname mismatch or untrusted CA), 527 Railgun Error (Cloudflare — WAN optimization connection error, rare and Railgun-specific), 530 Site Frozen (Pantheon hosting — site suspended for inactivity or non-payment), 561 Unauthorized (AWS ALB — client didn't present a valid mTLS certificate at the load balancer layer), Varnish 503 Guru Meditation (Varnish Cache — backend health check failed, use varnishlog to diagnose which backend and why), and the frontend vs backend status code mapping (how CDNs translate connection failures into meaningful HTTP codes — without a CDN, a crashed backend produces "Network Error" with no useful information).

How to Use This Cheat Sheet in Your Daily Workflow

Our Control Room-themed cheat sheet is designed for speed. Press Ctrl+K to jump to the search bar and type any status code (e.g., "502") or keyword (e.g., "rate limit" or "redirect"). The cards filter in real-time as you type. Click any card to copy its status code to your clipboard. The 10 category tabs let you focus on specific areas — click "5xx Server Error — Core" when debugging a production incident, or "3xx Redirection" when setting up URL redirects. Each card includes the status code number, when it appears, a detailed example with curl commands or HTTP request/response pairs, and practical debugging guidance. The status bar at the top visualizes the five HTTP code classes (1xx–5xx) as colored indicator lights, and the radar sweep animation gives the page a distinctive mission-control feel that makes debugging feel less like work and more like flying a spacecraft.

For related HTTP tools, see our curl Commands Cheat Sheet (the essential tool for testing HTTP status codes from the command line), our Linux Commands Cheat Sheet (for server-side debugging), and our Web APIs Cheat Sheet (for designing APIs that return the right status codes). For JSON data processing in API responses, see our jq Commands Cheat Sheet. For database troubleshooting, check our PostgreSQL Commands Cheat Sheet. All tools are free, interactive, and require no signup.

Frequently Asked Questions About HTTP Status Codes

What is the difference between 401 Unauthorized and 403 Forbidden?

401 Unauthorized means authentication is missing or invalid — the server doesn't know who you are. It must include a WWW-Authenticate header telling the client how to authenticate (Bearer, Basic, Digest, etc.). Return 401 when the user needs to log in or their token has expired. 403 Forbidden means the server knows who you are (authentication succeeded) but you lack permission to access this specific resource. Return 403 when the authenticated user tries to access another user's private data or an admin-only endpoint. Using 401 when the user is already authenticated is one of the most common API design mistakes — it confuses clients because they already have valid credentials.

When should I use 301 vs 302 vs 307 vs 308 for redirects?

These four redirect codes serve different purposes based on permanence and method preservation. 301 Moved Permanently — permanent redirect, search engines transfer ranking to the new URL, but browsers may change POST to GET (use for SEO page moves). 302 Found — temporary redirect, search engines keep the original URL indexed, but browsers may change POST to GET (legacy code, prefer 303 or 307). 307 Temporary Redirect — temporary redirect that preserves the HTTP method (POST stays POST, PUT stays PUT) — use for temporary API endpoint moves. 308 Permanent Redirect — permanent redirect that preserves the HTTP method — use for permanent API endpoint changes. For the standard Post-Redirect-Get pattern (form submission → redirect to confirmation page), always use 303 See Other.

What is the difference between 502 Bad Gateway and 504 Gateway Timeout?

502 Bad Gateway means the upstream server returned an invalid or incomplete response — the backend crashed mid-response, sent malformed HTTP, or returned something the proxy couldn't parse. 504 Gateway Timeout means the upstream server didn't respond at all within the configured timeout period (typically 60 seconds for Nginx, 30 seconds for AWS ALB). Check whether the backend process is running for 502; check whether the backend is overloaded or hung for 504. Both indicate the problem is on your upstream server, not the client and not the proxy.

Should validation errors return 400 or 422?

422 Unprocessable Entity is the de facto standard for semantic validation errors in REST APIs. Use 422 when the JSON parses correctly but the field values are invalid (email format wrong, age negative, required field missing, business rule violated). 400 Bad Request is for syntactically malformed requests (invalid JSON, unparseable body, missing Content-Type header). Most modern frameworks follow this convention: Rails, Laravel, and FastAPI all return 422 for validation failures, returning structured error objects with per-field messages that the client can map to form fields. This distinction helps clients distinguish between "fix your request format" (400) and "fix your data values" (422).

What do Cloudflare's 520–527 error codes mean?

Cloudflare's 52x series translates origin server connection problems into HTTP status codes that browsers can parse. 520: unknown/unexpected origin response. 521: origin server refused the TCP connection (web server down). 522: connection to origin timed out (server overloaded or network issue). 523: origin DNS/routing unreachable. 524: origin didn't send HTTP response within Cloudflare's timeout (100 seconds default). 525: SSL/TLS handshake with origin failed (certificate expired). 526: origin SSL certificate validation failed (hostname mismatch). 527: Railgun WAN optimization error (rare). Without these codes, clients would see a generic connection error with no diagnostic information.

What HTTP status code should I return for a successful DELETE operation?

The three common choices for DELETE responses are: 204 No Content (preferred — the resource is gone, there's nothing meaningful to return in a response body, the browser stays on the current page), 200 OK (with a response body containing the deleted resource or a confirmation message — useful when the client needs to confirm what was deleted), and 202 Accepted (for asynchronous deletion — the request was accepted but the resource hasn't been deleted yet, return a status URL for polling). 204 is the cleanest and most RESTful choice for synchronous deletes. If the resource doesn't exist, some APIs return 404 while others return 204 (idempotent — deleting a non-existent resource achieves the same end state).