HTTP Status Codes Reference (1xx–5xx) With Use Cases & RFCs

Search all 61 HTTP status codes by number, name, or use case — from 100 Continue to 511 Network Authentication Required. Filter by class, read a plain-English meaning and a real use case for each, and cite the exact RFC 9110 section. Free, 100% in-browser.

Showing 61 of 61 codes

1xx · Informational

Request received, continuing process.

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

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, nothing leaves your device. Works offline once loaded.

HTTP Status Codes Reference: Meaning, Use Case, and RFC for All 61 Codes

An HTTP status code is a three-digit number a server returns to say what happened to a request — success, redirect, client error, or server error. This reference lists all 61 codes, from 100 Continue to 511 Network Authentication Required, grouped into five classes. Type a number, name, or use case to filter instantly, and read each code's plain-English meaning plus its exact RFC 9110 section. It runs 100% in your browser, free, with no API lookups.

How to look up an HTTP status code

Type a code number (e.g. 404), a name (Unauthorized), or even a use case word (rate limit) into the search box — the list filters as you type.
Click a class filter — 1xx, 2xx, 3xx, 4xx, or 5xx — to narrow to one category, and combine it with search for a tight result set.
Read each card's plain-English description and the Example line showing a real-world use case.
Copy the RFC citation at the bottom of the card (e.g. RFC 9110 §15.5.21) straight into your API design doc or code review.
Press the clear button to reset the search and browse all 61 codes again.

What HTTP status codes mean and how the classes work

Every HTTP response starts with a status line containing a numeric code and a reason phrase, such as 200 OK or 404 Not Found. The first digit defines the class, which tells a client how to react before it even reads the body. The canonical definitions live in RFC 9110 (HTTP Semantics, 2022), the consolidated spec that replaced the older RFC 7231 family. RFC 9110 puts it plainly:

"The status code of a response is a three-digit integer code that describes the result of the request and the semantics of the response… The first digit of the status code defines the class of response."— RFC 9110, §15

This tool bundles RFC 9110 codes alongside widely-deployed extensions cited to their own RFCs — WebDAV (RFC 4918), rate limiting (RFC 6585, the source of 429), early hints (RFC 8297, 103), permanent method-preserving redirects (RFC 7538, 308), and legal blocks (RFC 7725, 451). A client only needs the first digit to route behavior: follow a 3xx automatically, fix the request on a 4xx, or retry a transient 5xx.

The five status code classes (1xx–5xx)

The counts below reflect exactly what this reference bundles — 61 codes in total.

Class	Meaning	Codes here	How a client reacts
1xx	Informational	4	Provisional — wait for the final response (100, 101, 103).
2xx	Success	10	Request received, understood, accepted (200, 201, 204).
3xx	Redirection	7	Follow the Location header, often automatically (301, 304, 308).
4xx	Client Error	29	Fix the request — bad input or no permission (400, 401, 404, 429).
5xx	Server Error	11	Retry a transient failure; the request itself was valid (500, 502, 503).

Worked examples: picking the right code

Create a resource

POST /users succeeds → return 201 Created with a Location header pointing at the new user, not a generic 200 OK.

Validation failure

JSON parsed fine but the email field is empty → return 422 Unprocessable Content. Reserve 400 Bad Request for body the server could not parse at all.

Rate limit hit

Client exceeded its quota → return 429 Too Many Requests with a Retry-After: 60 header so the client backs off for 60 seconds instead of retrying immediately.

Edge case · 301 vs 302 and SEO

For a permanent URL move, use 301, not 302. Contrary to the common myth, Google's John Mueller has confirmed that 302 redirects do pass PageRank — but a 302 signals temporary, so Google keeps the old URL as canonical until you switch to a 301 (or leave the 302 long enough that Google reinterprets it as permanent). Browsers also cache 301s permanently and 302s not. If the move is permanent and the endpoint accepts POST/PUT, use 308 so the method is preserved per RFC 9110.

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.

The detail other tables skip: search matches the use case, not just the number

This reference holds exactly 61 codes — 4 in 1xx, 10 in 2xx, 7 in 3xx, 29 in 4xx, and 11 in 5xx. The 4xx class is by far the largest because client mistakes have the most distinct, recoverable shapes. The search box does not just match the code number and name — it also scans each entry's description and use case text. So typing rate limit surfaces 429, websocket surfaces 101, and retry-after surfaces both 429 and 503, even though none of those words appear in the code name.

One honest limit: this is a static catalogue, not a live HTTP client. It does not fetch a URL or report the status a given server returns — it explains what each code means so you can choose or interpret the right one. Codes the spec reserves but never assigned (e.g. there is no standard 418 outside an April Fools' RFC) are flagged in their descriptions so you do not ship a joke code to production.

Runs 100% in your browser

Your searches never leave your device. All 61 codes are bundled into the page, so filtering happens locally in JavaScript with no API calls — no uploads, nothing leaves your device, and it works offline once loaded. I tested the search against code numbers (404, 422), partial names (unauth, teapot), and use-case phrases (rate limit, websocket, retry-after), plus every class filter, and the list stays instant on each keystroke.

Frequently asked questions

Is this HTTP status code lookup free, and does it run in my browser?

Yes. The reference is 100% free with no signup and no usage cap. All 61 status codes are bundled into the page, so search and filtering run entirely in your browser with JavaScript — nothing is sent to a server and the tool works offline once the page loads.

What is the difference between 401 and 403?

401 Unauthorized means the request lacks valid authentication — no credentials, or an expired or invalid token. The fix is to authenticate again (log in, refresh the token, supply the API key). 403 Forbidden means authentication succeeded but the authenticated user lacks permission for this specific resource; the fix is a role or policy change, not a re-login. The name "401 Unauthorized" is misleading — per RFC 9110 it really means "unauthenticated", but the legacy name was kept for compatibility.

When should I return 404 vs 410 vs 200?

Return 404 Not Found when the resource does not exist at this URL — it may never have existed or may exist again later. Return 410 Gone when the resource existed and was permanently removed; search engines treat 410 as a stronger de-indexing signal than 404. Return 200 OK with an empty array for collection endpoints where "no results" is a valid outcome, not an error — a successful query that found nothing is not a 404. The wrong choice breaks pagination, SEO, and client error handling.

What is 422 Unprocessable Content and when do I use it?

Return 422 when the server parsed the request body fine — valid JSON, valid XML — but the content failed semantic validation, such as a missing required field, a malformed email, or two fields that violate a business rule. Return 400 Bad Request when the body itself is malformed and could not be parsed at all. The distinction tells API consumers what to fix: 400 means "fix your encoding"; 422 means "your data is structured correctly but wrong". 422 was formerly named "Unprocessable Entity" in WebDAV and renamed in RFC 9110.

Does using 302 instead of 301 hurt SEO?

Not as much as the myth claims, but for a permanent move 301 is correct. Google's John Mueller has confirmed 302 redirects do pass PageRank, so the "302 kills link equity" belief is wrong. The real difference: a 301 signals a permanent move and is cached permanently by browsers, while a 302 signals temporary and keeps the original URL as canonical. Leave a 302 in place long enough and Google eventually treats it as a 301. For a genuine permanent move, use 301 (or 308 to preserve the method) so the new URL is indexed immediately.

What is the difference between 301, 302, 303, 307, and 308 redirects?

301 Moved Permanently allows clients to downgrade a POST to GET; 308 Permanent Redirect is the same permanent move but MUST NOT change the method (use it for POST/PUT API endpoints). For temporary redirects: 302 Found is historically ambiguous and best avoided, 303 See Other forces a GET on the target (the POST-redirect-GET pattern after a form submit), and 307 Temporary Redirect preserves the original method and body. Rule of thumb: 308 for permanent method-preserving, 303 for POST-redirect-GET, 307 for temporary method-preserving.

When should an API return 429 Too Many Requests?

Return 429 when a client exceeds a request quota — a per-second burst, hourly cap, or daily limit. Always include a Retry-After header (in seconds, like Retry-After: 60, or as an HTTP date) so clients back off correctly. Many APIs also send X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset on every response so clients can throttle preemptively. 429 should be transient; if the block is permanent (an account stuck on a free tier), 403 with an explanatory body fits better.

What is the difference between 500 and 503?

500 Internal Server Error is an unexpected failure — an unhandled exception, a bug, or a lost database connection. 503 Service Unavailable is an expected, temporary condition: planned maintenance, capacity overload, or a tripped circuit breaker. Always attach a Retry-After header to a 503 so clients know when to retry; without it they have no signal to back off and will hammer the server during the incident. Get the choice right and clients retry intelligently instead of amplifying an outage.

Which 1xx informational codes are actually used in production?

Three are common. 100 Continue lets a client check whether a server will accept a large upload before sending the body (send Expect: 100-continue and wait). 101 Switching Protocols is the response to a WebSocket upgrade handshake. 103 Early Hints (RFC 8297) is the modern star — a server sends 103 with Link: preload headers before the final 200 so the browser fetches CSS and JS while the backend composes the page, measurably improving LCP. Cloudflare, Chrome, and major frameworks all support 103.