100Continue
Initial part of the request received; client should continue. Typically a response to an Expect: 100-continue header.
Example — Large upload pre-flight check before sending the body.
RFC 9110 §15.2.1
HTTP Status Codes Reference (1xx–5xx) With Use Cases & RFCs
Complete searchable reference for every HTTP status code — the canonical RFC 9110 list plus widely-deployed extensions (WebDAV, rate-limiting, captive portal). Filter by category, search by code or name, and read each code's typical use case in plain English.
Showing 61 of 61 codes
1xx · Informational
Request received, continuing process.
101Switching Protocols
Server is switching protocols as requested via Upgrade header.
Example — HTTP/1.1 → WebSocket upgrade handshake.
RFC 9110 §15.2.2
102Processing
Server is processing the request but no response yet available. (WebDAV)
Example — Long-running WebDAV operations that exceed default timeouts.
RFC 2518
103Early Hints
Server is preparing the final response; client may begin processing Link headers (e.g. preload).
Example — Send preload hints before the full response is ready, improving LCP.
RFC 8297
2xx · Success
Action successfully received, understood, and accepted.
200OK
Standard success response with a body.
Example — GET that returns resource data; POST that completed synchronously.
RFC 9110 §15.3.1
201Created
Resource successfully created; typically returns a Location header pointing to the new resource.
Example — POST /users creating a new user; PUT creating a resource at the supplied URL.
RFC 9110 §15.3.2
202Accepted
Request accepted for processing but not yet completed; status check is the client's responsibility.
Example — Async job queued — return a job ID, expose a separate GET /jobs/:id endpoint.
RFC 9110 §15.3.3
203Non-Authoritative Information
Body is from a transforming proxy, not the origin server.
Example — Through a transparent proxy that modified the payload.
RFC 9110 §15.3.4
204No Content
Successful response with no body. Headers may still convey meta-information.
Example — DELETE that completed successfully; PUT update with no body to return.
RFC 9110 §15.3.5
205Reset Content
Tells the client to reset the document view (e.g. clear a form).
Example — After form submission, reset the input fields client-side.
RFC 9110 §15.3.6
206Partial Content
Successful range request — returning only the requested byte range.
Example — Video streaming; resume of an interrupted download via Range header.
RFC 9110 §15.3.7
207Multi-Status
Body contains multiple status codes for batched WebDAV operations.
Example — WebDAV PROPFIND, COPY, MOVE responses with per-resource statuses.
RFC 4918
208Already Reported
In a Multi-Status response, the member was already reported elsewhere. (WebDAV)
Example — WebDAV bindings — avoid reporting duplicate state.
RFC 5842
226IM Used
Server fulfilled the request using one or more instance manipulations.
Example — Delta encoding for cache-aware updates (rare in practice).
RFC 3229
3xx · Redirection
Further action required to complete the request.
300Multiple Choices
Multiple response options exist; the client picks one (rarely used).
Example — Content-negotiation fallback when no preferred match is found.
RFC 9110 §15.4.1
301Moved Permanently
Resource permanently moved to the URL in the Location header. SEO signal: pass link equity.
Example — Site migration; URL restructuring. Cached and bookmarked aggressively by browsers.
RFC 9110 §15.4.2
302Found
Resource temporarily at the URL in Location. Historically ambiguous — prefer 303 or 307.
Example — Legacy redirect after form submission (modern code should use 303 or 307).
RFC 9110 §15.4.3
303See Other
Forces a GET request on the redirect target, regardless of the original method.
Example — POST/Redirect/GET pattern — after a successful POST, redirect to a confirmation page.
RFC 9110 §15.4.4
304Not Modified
Conditional GET succeeded but the resource has not changed. Body is empty; reuse cached version.
Example — Browser cache validation via If-None-Match (ETag) or If-Modified-Since.
RFC 9110 §15.4.5
307Temporary Redirect
Same as 302 but the HTTP method MUST NOT change. Use instead of 302 for non-GET methods.
Example — A/B testing redirect on a POST endpoint; preserves request method and body.
RFC 9110 §15.4.8
308Permanent Redirect
Same as 301 but the HTTP method MUST NOT change. Modern replacement for 301 with method preservation.
Example — Permanent move of an API endpoint that accepts POST/PUT; clients keep their method.
RFC 7538
4xx · Client Error
Request contains bad syntax or cannot be fulfilled.
400Bad Request
Request cannot be processed due to client error (malformed syntax, invalid framing, etc.).
Example — Malformed JSON body; missing required query parameter.
RFC 9110 §15.5.1
401Unauthorized
Authentication required and has either not been provided or has failed. Misnamed — should be "Unauthenticated".
Example — Missing or expired Bearer token; invalid API key.
RFC 9110 §15.5.2
402Payment Required
Reserved for future use; sometimes adopted by APIs for quota or billing-related rejections.
Example — API exceeded paid-tier quota; account in arrears.
RFC 9110 §15.5.3
403Forbidden
Server understood the request but refuses to authorize it. Authentication is valid but insufficient.
Example — User authenticated but lacks permission for this resource.
RFC 9110 §15.5.4
404Not Found
Server cannot find the requested resource. May also be used to obscure existence (vs 403).
Example — Mistyped URL; deleted resource; resource never existed.
RFC 9110 §15.5.5
405Method Not Allowed
Method known but not supported on this resource. MUST include Allow header listing valid methods.
Example — DELETE on a read-only endpoint; POST on a GET-only resource.
RFC 9110 §15.5.6
406Not Acceptable
No representation matches the client's Accept-* headers.
Example — Client demands Accept: application/xml but server only emits JSON.
RFC 9110 §15.5.7
407Proxy Authentication Required
Like 401 but the proxy requires authentication.
Example — Corporate proxy demanding sign-in before forwarding the request.
RFC 9110 §15.5.8
408Request Timeout
Server timed out waiting for the request to complete.
Example — Idle keep-alive connection closed by server after timeout window.
RFC 9110 §15.5.9
409Conflict
Request conflicts with the current state of the target resource (concurrent modification).
Example — PUT with stale If-Match ETag; create-if-not-exists where the resource already exists.
RFC 9110 §15.5.10
410Gone
Resource intentionally removed and will not return. Stronger SEO signal than 404 for de-indexing.
Example — Deprecated API endpoint that has been removed; canceled user account.
RFC 9110 §15.5.11
411Length Required
Server refuses the request without a Content-Length header.
Example — POST without Content-Length where the server cannot use chunked encoding.
RFC 9110 §15.5.12
412Precondition Failed
One or more conditions in the request headers (If-Match, If-Unmodified-Since) failed.
Example — Optimistic concurrency control — request rejected because the resource changed.
RFC 9110 §15.5.13
413Content Too Large
Request body exceeds the server's configured limit. (Formerly "Payload Too Large".)
Example — Upload over the 100 MB body cap; oversized JSON payload.
RFC 9110 §15.5.14
414URI Too Long
Request URI exceeds the server's length limit.
Example — GET with too many query parameters (move to POST with a body).
RFC 9110 §15.5.15
415Unsupported Media Type
Request body media type is not supported by the resource.
Example — Content-Type: text/xml on a JSON-only API.
RFC 9110 §15.5.16
416Range Not Satisfiable
Range header specifies a range outside the resource size.
Example — Byte-range request that starts beyond end-of-file.
RFC 9110 §15.5.17
417Expectation Failed
Server cannot satisfy the Expect request header.
Example — Client sent Expect: 100-continue but server refuses.
RFC 9110 §15.5.18
418I'm a Teapot
HTCPCP joke status — should never be used in production but persists in many frameworks.
Example — Honeypots; humorously rejecting brewing-related requests.
RFC 2324 (April 1)
421Misdirected Request
Request directed at a server unable or unwilling to produce a response.
Example — HTTP/2 connection reuse to a server that does not serve this hostname.
RFC 9110 §15.5.20
422Unprocessable Content
Body well-formed but semantically invalid. (Formerly "Unprocessable Entity".)
Example — JSON parses fine but business validation fails (email format, required field combinations).
RFC 9110 §15.5.21
423Locked
Resource is locked by another client. (WebDAV)
Example — WebDAV LOCK conflict; collaborative editing exclusive lock.
RFC 4918
424Failed Dependency
Request failed because it depended on a prior request that failed. (WebDAV)
Example — WebDAV multi-step operation where the prerequisite step returned an error.
RFC 4918
425Too Early
Server unwilling to process early-data request (TLS 1.3 0-RTT).
Example — Replay protection for non-idempotent requests sent in 0-RTT data.
RFC 8470
426Upgrade Required
Server refuses to use the current protocol; client must upgrade.
Example — Server-side deprecation of HTTP/1.0; mandate TLS upgrade.
RFC 9110 §15.5.22
428Precondition Required
Origin server requires the request to be conditional (prevent lost-update).
Example — API that mandates If-Match for all PUT requests to enforce optimistic concurrency.
RFC 6585
429Too Many Requests
User has sent too many requests in a given amount of time (rate limiting). Often includes Retry-After header.
Example — Rate-limit exceeded; bot detection; quota enforcement.
RFC 6585
431Request Header Fields Too Large
Server refuses because the combined header fields are too large.
Example — Cookie bomb attack; over-stuffed Authorization header.
RFC 6585
451Unavailable For Legal Reasons
Resource unavailable due to legal demands (court order, censorship).
Example — GDPR right-to-erasure compliance; geo-blocked content; takedown notice.
RFC 7725
5xx · Server Error
Server failed to fulfill an apparently valid request.
500Internal Server Error
Generic server-side error; no more specific message available. Catch-all for unexpected failures.
Example — Unhandled exception; bug in handler code; database connection lost.
RFC 9110 §15.6.1
501Not Implemented
Server does not support the functionality required to fulfill the request.
Example — PATCH method requested on a server that does not implement it.
RFC 9110 §15.6.2
502Bad Gateway
Server acting as gateway received an invalid response from the upstream.
Example — Load balancer cannot connect to the backend; upstream returned malformed response.
RFC 9110 §15.6.3
503Service Unavailable
Server temporarily unavailable due to maintenance or overload. May include Retry-After.
Example — Planned downtime; circuit-breaker tripped; capacity protection.
RFC 9110 §15.6.4
504Gateway Timeout
Gateway did not receive a timely response from the upstream server.
Example — Slow database query exceeded reverse-proxy timeout; serverless cold start beyond limit.
RFC 9110 §15.6.5
505HTTP Version Not Supported
Server does not support the HTTP protocol version used in the request.
Example — Client trying HTTP/0.9 on a modern server.
RFC 9110 §15.6.6
506Variant Also Negotiates
Transparent content negotiation loop — chosen variant itself negotiates.
Example — Misconfigured negotiation rules creating a referential loop.
RFC 2295
507Insufficient Storage
Server cannot store the representation needed to complete the request. (WebDAV)
Example — WebDAV PUT to a quota-exhausted directory.
RFC 4918
508Loop Detected
Server detected an infinite loop while processing a request with Depth: infinity. (WebDAV)
Example — WebDAV PROPFIND on a tree with cyclic bindings.
RFC 5842
510Not Extended
Further extensions to the request are required for the server to fulfill it.
Example — HTTP Extension Framework — practically deprecated.
RFC 2774
511Network Authentication Required
Client needs to authenticate to gain network access (captive portal).
Example — Public Wi-Fi captive-portal redirect detection.
RFC 6585
Instant Search
Type a code (e.g. "422") or part of a name ("unauthorized", "rate limit") to filter the list in real time as you type — no submit, no reload.
Filter by Category
One-click filters for 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error). Combine with search for narrow results.
RFC Citations
Each entry cites the canonical RFC and section. RFC 9110 is the 2022 consolidated HTTP semantics spec; legacy and extension codes cite their original sources.
100% Static Reference
The data is bundled with the page — no API calls, no tracking of which codes you look up. Works offline once loaded.
Every HTTP Status Code, With Real-World Context
HTTP status codes are the universal vocabulary of web communication — three-digit signals from server to client that compress the entire outcome of a request into a single integer. Most developers know 200, 404, and 500 cold, but the difference between 422 and 400, or 401 and 403, sends countless production bugs into the wrong layer of the stack. This complete HTTP status code reference covers every code defined in RFC 9110 (the consolidated 2022 HTTP semantics spec) plus widely-deployed extensions from WebDAV, rate-limiting, captive-portal, and early-hints RFCs. Each entry includes the canonical name, plain-English description, a typical real-world use case, and the RFC citation you can take to your team's API design review.
Pair this with our JSON Formatter (inspect API response bodies), JWT Decoder (debug 401 token issues), URL Encoder (sanitize query params that cause 414s), and the Timestamp Converter (parse Retry-After HTTP-date values).
Commonly Confused Status Codes
| Pair | Why It Matters |
|---|---|
| 301 vs 308 | 301 may allow user-agents to change the method to GET (legacy); 308 preserves the original method. Use 308 for modern permanent moves of non-GET endpoints. |
| 302 vs 303 vs 307 | 302 is ambiguous (legacy). 303 forces GET on the redirect. 307 preserves the method. Modern code should pick 303 (POST-redirect-GET) or 307 (preserve everything), never plain 302. |
| 401 vs 403 | 401 = not authenticated (no/bad credentials). 403 = authenticated but not authorized for this specific resource. Get the distinction wrong and your API consumers will spend hours debugging the wrong layer. |
| 404 vs 410 | 404 = "I don't know about this" (may exist later). 410 = "It existed and is gone for good" (de-index in search engines). Use 410 for explicit permanent removals. |
| 422 vs 400 | 400 = malformed syntax (couldn't parse). 422 = parsed fine but semantically invalid (e.g. JSON OK, but email field is empty). 422 is more informative for API consumers. |
| 500 vs 503 | 500 = unexpected internal failure (a bug). 503 = expected, temporary unavailability (overload, maintenance). 503 with Retry-After lets clients back off correctly. |
What Each Category Class Means
1xx
Informational
Provisional response; final response still coming
2xx
Success
Request received, understood, and accepted
3xx
Redirection
Further action needed (often automatic follow)
4xx
Client Error
Request fault — fix the client to succeed
5xx
Server Error
Server fault — client request was valid
Status Code Best Practices for REST APIs
1. Be Specific
Returning 500 for everything strips diagnostic signal. Use 422 for validation errors, 409 for concurrent-modification conflicts, 429 for rate limits — your clients will retry intelligently.
2. Always Include Retry-After
For 429 and 503, set Retry-After so clients back off correctly. Without it, well-meaning clients hammer the server during incidents.
3. 401 = Re-auth, 403 = Re-policy
Get this distinction right or your clients will refresh tokens forever against a permission problem. The two require different fixes at different layers.
4. Match Body to Code
Error responses should include a structured JSON body (RFC 9457 Problem Details) with code, message, and trace ID. Status alone is not enough for clients to act on.