--- title: "HTTP Status Codes Reference" description: "Every standard HTTP status code with a plain-English description. Search by code, name, or keyword; filter by class." url: "https://freshjuice.dev/tools/http-status-codes/" --- ## About this reference All 1xx–5xx codes from the HTTP RFCs (9110, 9112), WebDAV (RFC 4918), and assorted extensions, with short developer-facing descriptions. Search accepts a code (`404`), a class (`5xx`), or any word from the name or description. ## The five classes - **1xx** — informational; the request was received, keep going. - **2xx** — success; the request did what you asked. - **3xx** — redirection; the resource lives somewhere else (or hasn't changed). - **4xx** — client error; the request itself is wrong. - **5xx** — server error; the request was fine, the server failed. Yes, [418 I'm a teapot](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418) is real — RFC 2324, April Fools 1998, later officially reserved so it can never mean anything serious. ## Frequently Asked Questions ### What's the difference between 301 and 302? Permanence. A **301** tells crawlers and browsers "this moved forever, update your records": search engines transfer ranking signals to the new URL and browsers cache the redirect. A **302** says "temporary, keep requesting the original". Using 301 for a temporary promo page burns the old URL's SEO; using 302 for a permanent migration fails to consolidate signals. Related: **308** and **307** are the method-preserving versions (POST stays POST). ### When should I use 410 instead of 404? A **404** means "not found": could be a typo, could be gone, could be back later. A **410** means "gone, deliberately, forever". Google deindexes 410s faster because the intent is explicit. Use 404 for accidental gaps, 410 for content you intentionally removed and want dropped from the index quickly. ### Why does my API return 422 instead of 400? A **400** is malformed syntax: the request isn't valid HTTP or JSON at all. A **422** is well-formed but semantically wrong: the JSON parses, but a field fails validation (an email without an `@`, a negative age). Many APIs skip 422 and use 400 for everything; that's acceptable, but 422 gives clients a precise way to distinguish "your request was garbage" from "your request parsed but the values are wrong". ### What does 429 mean and how should a client respond? **429 Too Many Requests**: you hit a rate limit. The well-behaved response is to read the `Retry-After` header (seconds to wait, or an HTTP-date) and honor it, applying exponential backoff with jitter if the header is missing. Hammering a 429 endpoint is how temporary limits become permanent blocks. ### Are all 5xx errors my server's fault? Loosely: 5xx means the server failed to fulfill a valid request, but the trigger isn't always your code. **502** and **504** usually come from a gateway or proxy (nginx, Cloudflare) that couldn't reach your app or timed out waiting for it: crashed worker, upstream timeout, DNS misconfiguration. **500** is the generic "code blew up" case. When debugging, check whether the error originated at the edge or the origin before blaming the app. ### Can I invent my own status codes? Don't. Unassigned codes in each class can be defined by future RFCs, so your custom 599 today may collide with a standardized meaning tomorrow. The convention when you need app-specific errors: use an appropriate standard code (400, 422, 500) and carry the detail in the body, like `{"error": "...", "code": "SOME_DETAIL"}`. Twitter's old 420 "Enhance Your Calm" was memorable precisely because it broke this rule. ### Is 418 I'm a teapot a joke? Yes and officially so: RFC 2324, published April 1st, 1998, for the Hyper Text Coffee Pot Control Protocol. The IETF later reserved the code so it can never be reassigned to anything serious. Google returns it from `google.com/teapot`. Harmless fun; just don't use it for real error handling.