HTTP Status Codes Lookup Online

How to Look Up an HTTP Status Code

1. Enter the Code or Pick a Category: Type a three-digit code (e.g., 301, 404, 503) into the search box, or click a category — 1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Error, or 5xx Server Error — to browse every code in that class.
2. Read the Definition: The result shows the official IANA-registered name, the defining RFC (RFC 9110 for the core set, plus RFC 6585, RFC 7725, RFC 8297, and RFC 8470 for extensions), and a plain-English description of when servers actually emit it.
3. Compare Related Codes: Use the side-by-side rows below to disambiguate look-alikes — 301 vs 308, 302 vs 307, 401 vs 403, 404 vs 410, 502 vs 503 vs 504. The "use it when" column tells you which to pick when you're the one writing the API.
4. Copy and Apply: Click any row to copy the code number, name, or full definition. Useful for OpenAPI specs, error documentation, monitoring dashboards, and Nginx/Apache error pages. Everything runs in your browser — nothing is logged.

Why HTTP Status Codes Matter

Every HTTP response — from a healthcheck on pod.xconvert.com to a curl against a REST API — carries a three-digit status code. Picking the right one (or correctly interpreting one your client received) is the difference between Google indexing your removed pages, your monitoring system paging at 3 AM for a transient 429, or your frontend silently swallowing failures because the backend returned 200 OK with {"error": "..."} in the body. Common scenarios:

• SEO and crawl-budget hygiene — Google treats 404 and 410 identically for indexing purposes (per Google Search Central's HTTP status code reference, all 4xx except 429 mean "this URL doesn't exist"), but the crawl-frequency decay is the same; emit a real 404/410 rather than a soft 404 (a 200 with "page not found" text), which Search Console flags and which wastes crawl budget.
• REST API correctness — Returning 200 OK with {"success": false, "error": "..."} is a well-known anti-pattern: HTTP middleware, retry libraries, and observability tools all key off the status code. Use 4xx for client mistakes (validation, auth) and 5xx for server faults, with the JSON body carrying the detail (RFC 9457 application/problem+json is the modern standard).
• Rate limiting and backoff — 429 Too Many Requests (RFC 6585) is the right code for "slow down"; pair it with a Retry-After header so well-behaved clients (and Google's crawler) know how long to wait. Don't use 403 for rate limiting — Google explicitly warns against this because it looks like a permanent block.
• Maintenance windows — 503 Service Unavailable with Retry-After tells Googlebot to come back later and preserves rankings; a hard 500 for an extended period eventually drops URLs from the index.
• Auth flows — 401 Unauthorized means "I don't know who you are" (send credentials); 403 Forbidden means "I know who you are and you can't have it." Returning 404 instead of 403 for a forbidden resource is a defensible privacy choice (don't leak existence), but 401-vs-403 confusion breaks SPA auth-redirect logic.
• Redirect semantics — 301/308 are permanent (clients and SEO crawlers update bookmarks/links); 302/307 are temporary. 307/308 preserve the HTTP method (POST stays POST); 301/302 historically allowed POST → GET rewrites and most browsers still do. If you're redirecting a form submission, use 307 or 308.

HTTP Status Codes by Class — Quick Reference

Codes below are the IANA-registered set most commonly seen in production. The "Defined in" column lists the current authoritative RFC.

Code	Name	Class	Defined in	What it actually means
100	Continue	1xx	RFC 9110 §15.2.1	Server accepts request headers; client should send the body
101	Switching Protocols	1xx	RFC 9110 §15.2.2	Server is switching protocols (WebSocket upgrade, HTTP/2 upgrade)
103	Early Hints	1xx	RFC 8297	Preload hints before the final response; used by Cloudflare, Fastly
200	OK	2xx	RFC 9110 §15.3.1	Generic success; body contains the requested resource
201	Created	2xx	RFC 9110 §15.3.2	New resource created (POST/PUT); Location header points to it
202	Accepted	2xx	RFC 9110 §15.3.3	Async — request queued, processing has not finished
204	No Content	2xx	RFC 9110 §15.3.5	Success with empty body (DELETE, PUT updates)
206	Partial Content	2xx	RFC 9110 §15.3.7	Range request fulfilled — video seek, resumable downloads
301	Moved Permanently	3xx	RFC 9110 §15.4.2	URL changed forever; update links/bookmarks
302	Found	3xx	RFC 9110 §15.4.3	Temporary — keep using the original URL
303	See Other	3xx	RFC 9110 §15.4.4	After POST, GET this other URL (POST-redirect-GET pattern)
304	Not Modified	3xx	RFC 9110 §15.4.5	Cached copy is still good; no body
307	Temporary Redirect	3xx	RFC 9110 §15.4.8	Like 302 but method must be preserved
308	Permanent Redirect	3xx	RFC 9110 §15.4.9	Like 301 but method must be preserved
400	Bad Request	4xx	RFC 9110 §15.5.1	Client-side error — malformed JSON, bad parameters
401	Unauthorized	4xx	RFC 9110 §15.5.2	Authenticate (the name is a misnomer — it means unauthenticated)
403	Forbidden	4xx	RFC 9110 §15.5.4	Authenticated but not allowed
404	Not Found	4xx	RFC 9110 §15.5.5	Resource doesn't exist (or you don't want to admit it does)
405	Method Not Allowed	4xx	RFC 9110 §15.5.6	Wrong verb — sent POST to a GET-only endpoint
408	Request Timeout	4xx	RFC 9110 §15.5.9	Client took too long to send the request
409	Conflict	4xx	RFC 9110 §15.5.10	Update conflict — concurrent edit, version mismatch
410	Gone	4xx	RFC 9110 §15.5.11	Intentionally removed forever; don't come back
415	Unsupported Media Type	4xx	RFC 9110 §15.5.16	Content-Type not accepted
418	(Unused) — "I'm a teapot"	4xx	RFC 9110 §15.5.19	Reserved; originally RFC 2324 (April 1, 1998) HTCPCP joke
421	Misdirected Request	4xx	RFC 9110 §15.5.20	Wrong server in a connection-coalesced HTTP/2 setup
422	Unprocessable Content	4xx	RFC 9110 §15.5.21	Syntactically valid but semantically wrong (validation failed)
425	Too Early	4xx	RFC 8470	Server won't process replayed early-data (TLS 1.3 0-RTT)
429	Too Many Requests	4xx	RFC 6585	Rate limit exceeded; respect Retry-After
451	Unavailable For Legal Reasons	4xx	RFC 7725	Court order, government takedown (number references Bradbury's Fahrenheit 451)
500	Internal Server Error	5xx	RFC 9110 §15.6.1	Catch-all — unhandled exception, NullPointerException
501	Not Implemented	5xx	RFC 9110 §15.6.2	Method not supported (e.g., PATCH on a GET-only server)
502	Bad Gateway	5xx	RFC 9110 §15.6.3	Reverse proxy got an invalid response from upstream
503	Service Unavailable	5xx	RFC 9110 §15.6.4	Temporarily down — maintenance, overload; use Retry-After
504	Gateway Timeout	5xx	RFC 9110 §15.6.5	Reverse proxy waited too long for upstream
511	Network Authentication Required	5xx	RFC 6585	Captive portal — must sign in to the network (hotel/airport Wi-Fi)

Common Look-Alikes — Which Code Should I Use?

Decision	Pick this	Not this	Why
Permanent URL change	301 or 308	302/307	Permanent codes update SEO links, bookmarks, HSTS-cached redirects
Permanent redirect after POST	308	301	301 historically allowed POST → GET rewrite; 308 mandates method preservation
Temporary maintenance	503 + Retry-After	500	503 signals "come back later"; 500 looks like a real bug
Resource deleted forever	410	404	Functionally identical for Google, but 410 is the semantically honest answer
Resource just doesn't exist	404	410	Default for unknown URLs; 410 implies intent to remove
Need to authenticate	401 + WWW-Authenticate	403	401 prompts the client to send credentials
Authenticated but blocked	403	401	403 = "stop sending creds; you still can't have it"
Validation failure on JSON body	422	400	400 is for malformed syntax; 422 is for "JSON parses but is wrong"
Rate limited	429 + Retry-After	403 / 503	Google explicitly says don't use 403 for throttling
Wrong HTTP verb	405 + Allow header	400	405 must include Allow listing supported verbs
Upstream timeout	504	500	504 signals the bug is upstream, not in your gateway

Frequently Asked Questions

What's the actual difference between 404 and 410, and does Google care?

Semantically, 404 Not Found means "I don't have this; it may or may not have existed; come back later if you want." 410 Gone means "I'm telling you this URL was deliberately removed and isn't coming back." Operationally, Google treats them the same: per the Search Central documentation on HTTP status codes ("How HTTP Status Codes Affect Google's Crawlers"), all 4xx responses except 429 cause indexed URLs to be removed and crawl frequency to gradually decrease. The old folk wisdom that "410 deindexes faster than 404" was never confirmed by Google and has been explicitly contradicted by John Mueller and the documentation. Use 410 when you want to be semantically precise (e.g., a sunset API endpoint); use 404 as the default.

What's the difference between 401 and 403?

401 Unauthorized is misnamed — it actually means "unauthenticated." Send it when the request has no credentials, has expired credentials, or has credentials the server can't validate. It must include a WWW-Authenticate header telling the client how to authenticate. 403 Forbidden means "I know who you are and you still can't have it." Send it for permission failures: a regular user hitting /admin, an unverified email trying to post, a free-tier user hitting a paid endpoint. A common SPA bug is treating 401 and 403 the same and infinite-looping the login redirect.

Is 418 I'm a teapot real?

Yes, with caveats. RFC 2324 was published April 1, 1998 as the Hyper Text Coffee Pot Control Protocol (HTCPCP) — a joke. RFC 7168 (also April 1, 2014) extended it for tea appliances. In 2017, Mark Nottingham (chair of the IETF HTTPBIS working group) proposed removing 418 from libraries that implemented it, arguing it was never part of HTTP proper. A teenager named Shane Brunswick launched save418.com, the campaign went viral, and Node.js, Go, ASP.NET, and Python's requests all kept it. RFC 9110 (June 2022, the current HTTP semantics specification) reserves 418 in the IANA registry — officially "(Unused)" — and notes it "was defined in Section 2.3.2 of RFC 2324, and therefore cannot be assigned any non-joke semantics for the foreseeable future." So: officially reserved, not officially endorsed, widely supported.

What's the right way to do rate limiting — what status code and headers?

429 Too Many Requests (RFC 6585) plus a Retry-After header containing either seconds (Retry-After: 60) or an HTTP-date. Many APIs also include RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset headers (draft-ietf-httpapi-ratelimit-headers). Do not use 403 Forbidden for rate limiting — Google's developer documentation explicitly warns against this in the post "Don't use 403s or 404s for rate limiting" because crawlers will eventually deindex URLs returning persistent 403s. Also avoid 503 for per-client throttling: 503 should mean the whole service is down, not that this particular caller is being throttled.

What is 451 Unavailable For Legal Reasons actually used for?

451 was added by RFC 7725 in 2016. The status code number is a deliberate reference to Ray Bradbury's Fahrenheit 451, in which books are banned. It's used when a server denies access because of a legal demand — a court order, a DMCA takedown, a national-level content block (e.g., GDPR-mandated geoblocking, country-specific censorship). The response should include a Link header with rel="blocked-by" pointing to the entity that issued the demand, when legally permitted. Major adopters: GitHub returns 451 on DMCA-removed repos, the Wikimedia Foundation uses it for legally-removed pages, and some EU geoblocked content returns it.

Is returning 200 OK with {"success": false, "error": "..."} in the JSON body ever okay?

No, treat this as an anti-pattern. HTTP status codes exist precisely so that middleware, retry libraries, monitoring tools, CDN edge logic, browser fetch interceptors, and metrics dashboards can all branch on success/failure without parsing your idiosyncratic JSON envelope. If you return 200 for errors you'll write if (response.status === 200 && response.body.success) everywhere, double-check on every consumer, and break tools like Prometheus' http_requests_total{status="2xx"} counters and Datadog's APM error tracking. The right pattern is the proper status code (4xx for client errors, 5xx for server errors) plus a structured body — RFC 9457 (application/problem+json) defines a standard schema with type, title, status, detail, and instance fields, and is widely supported.

Do HTTP/2 and HTTP/3 use different status codes than HTTP/1.1?

No — status codes are part of HTTP semantics (RFC 9110), which is shared across all HTTP versions. HTTP/2 (RFC 9113) and HTTP/3 (RFC 9114) only change the wire format (framing, multiplexing, transport: TCP+TLS for HTTP/2, QUIC for HTTP/3). The same 200, 301, 404, 429, 503 mean exactly the same thing whether your client is curl --http1.1, curl --http2, or curl --http3. The one HTTP/2-specific addition is 421 Misdirected Request, used when an HTTP/2 connection has been coalesced across hostnames (per RFC 7540, now superseded by RFC 9110/9113) and the server can't serve that authority.

What is a "soft 404" and why does Google flag it in Search Console?

A soft 404 is when a server returns 200 OK for a page that's effectively a "not found" page — empty content, "Sorry, this page doesn't exist" text, or a thin error template — instead of a real 404/410. Google's crawler infers from the page content that it's an error page and flags it as "Soft 404" in Search Console's Coverage report. Soft 404s waste crawl budget (Google keeps crawling URLs that should be dead), can pollute search results with low-quality pages, and signal site-quality issues at scale. Fix: return a real 404 (or 410 for intentionally removed pages), and make sure your custom error template is served with the correct status, not from a 200-returning catch-all handler.

What about 503 Service Unavailable during deployments — does it hurt SEO?

Short bursts of 503 are fine and are actually the right answer during deployments or maintenance windows. Per Google Search Central, 5xx responses signal "server overloaded" — crawlers temporarily slow down and indexed URLs are preserved. Once 2xx resumes, the crawl rate gradually recovers. Two practical guidelines: (1) Include Retry-After (seconds or HTTP-date) so the crawler knows when to come back. (2) If 5xx persists for more than a few days, Google starts dropping URLs from the index — so don't sit on 503 for a week thinking it's a free pause. For planned downtime longer than ~24 hours, switch to a 503 with a clear Retry-After, and aim to be back well before the timer.