All processing runs in your browser — no files or inputs are uploaded to a server.
HTTP groups status codes into five classes by the first digit. The classes are coarse — a single category covers everything from "keep going" to "all your fonts are missing" — but the digit alone tells a client whether the request worked, what went wrong, and whose fault it is.
| Class | Range | Name | What it actually means |
|---|---|---|---|
| 1xx | 100–199 | Informational | Interim response. The request was received and processing continues — the final response is still on its way. |
| 2xx | 200–299 | Success | The request succeeded. The exact semantics depend on the method — 200 for GET, 201 for created resources, 204 for "done, nothing to return". |
| 3xx | 300–399 | Redirection | Further action is needed by the client — usually a different URL to follow, sometimes a cached copy is still valid. |
| 4xx | 400–499 | Client error | The client did something wrong — bad syntax, missing auth, asking for something that does not exist, or sending data the server cannot accept. |
| 5xx | 500–599 | Server error | The server failed to fulfill an apparently valid request. The fault is server-side; the client did nothing wrong. |
A handful of code pairs cause the majority of real-world API bugs because the names sound interchangeable. The split is intentional — picking the right one tells the client what to do next.
401Unauthorized— the client is not authenticated. The server needs credentials and got none, or got bad ones. The "Unauthorized" wording is misleading — it really means "unauthenticated".403Forbidden— the client is authenticated but does not have permission. Re-authenticating will not help.301Moved Permanently— the resource has a new permanent URL. Browsers may rewrite the method to GET on redirect (legacy behavior).302Found— temporary redirect, same legacy method-rewriting behavior. Often what people accidentally use when they meant 303 or 307.307Temporary Redirect— like 302 but the method must be preserved. A POST stays a POST after redirect.308Permanent Redirect— like 301 but the method must be preserved. Modern equivalent of 301.200OK— a generic success with a body. Default for GET.201Created— a new resource was created. Include a Location header pointing at it.202Accepted— the request was queued — work has not started, will finish asynchronously.204No Content— success, but the response body is intentionally empty. Default for successful DELETE.400Bad Request— the request itself was malformed — invalid JSON, missing required header, etc. The server could not parse it.422Unprocessable Content— the request was understood but the data is semantically wrong — e.g. an email field had no @, or a quantity was negative.502Bad Gateway— a proxy got an invalid response from an upstream server. The upstream replied with something the proxy could not use.503Service Unavailable— the server itself is temporarily down — overload, maintenance window, etc. Often paired with a Retry-After header.504Gateway Timeout— a proxy waited too long for an upstream and gave up. Different from 502: 504 is "no answer", 502 is "bad answer".For a REST API, the conventional mapping is short. Successful GET: 200 (with body) or 304 (cached, unchanged). Successful POST that creates a resource: 201 with a Location header. Successful PUT or PATCH: 200 (with the updated body) or 204 (no body). Successful DELETE: 204. Validation failure: 422. Missing auth: 401. Authorized but no permission: 403. Resource not found: 404. Server bug: 500.
Two anti-patterns are common enough to call out. First, returning 200 with an error message in the body ("status: 200, error: 'not found'") breaks every monitoring tool — they all key off the status code. Second, returning 500 for every kind of failure leaves the client with no way to distinguish "retry this" (503) from "your input is wrong" (400) from "contact support" (500).
The current authoritative reference is RFC 9110 (HTTP Semantics, June 2022), which consolidates twelve earlier RFCs into one document and explicitly obsoletes RFC 7231 and RFC 7232. Most of the codes you use day-to-day were already in RFC 1945 (HTTP/1.0, 1996); 308 Permanent Redirect was added by RFC 7538, 421 Misdirected Request by RFC 7540, and 451 Unavailable For Legal Reasons by RFC 7725.
For practical lookup, the IANA HTTP Status Code Registry is the live source — it lists every assigned code with its defining RFC. If you need the formal wording for an audit or compliance report, cite RFC 9110 plus the registry; if you just need to remember what 422 means, the search box above is faster.
Type a code, a name, or a use-case keyword into the search box (`404`, `not found`, `redirect`, `unauthorized`, `idempotent`) and the table filters live. Click a class chip (1xx / 2xx / 3xx / 4xx / 5xx) to narrow further. Each row carries the canonical name, a one-line description, a "when to use" hint, and a link to the IETF section that defines it — `RFC 9110` for the core 2022 revision that replaced the long-lived RFC 7231 / 7232 / 7233 / 7234 / 7235 series.
Reach for this when designing an API, reading server logs, or debugging a request that surfaces an unfamiliar code. The 4xx / 5xx classes get most of the attention, but the 3xx redirect codes and the 2xx success codes have real semantic weight — `301` vs `308`, `200` vs `204` vs `201`, `409` vs `422` all communicate different things to caches and clients. Picking the right code makes integration with libraries (axios, RestSharp, Spring) and infrastructure (CloudFront, nginx, AWS API Gateway) behave predictably without custom hooks.
search: 422
422 Unprocessable Content (RFC 9110 §15.5.21) Use: request is syntactically valid but the server cannot process it for semantic reasons — failed validation, business rule violation. Often confused with 400.
`400 Bad Request` means the request itself is malformed (broken JSON, missing required header). `422` means the request was understood but its meaning is wrong (email already in use, age must be ≥ 18). Most modern APIs (Stripe, GitHub, Twilio) prefer `422` for validation errors so backend logs separate "client sent garbage" from "client tried something we cannot do".
search: redirect permanent
301 Moved Permanently — historic permanent redirect; browsers may rewrite the method to GET on POST / PUT. 308 Permanent Redirect (RFC 7538) — same semantics but preserves the original method and body.
Use `308` for new API endpoints when you want clients to keep using POST / PUT after the redirect. Use `301` for SEO and old-URL → new-URL moves where rewriting to GET is fine (and historically expected). The same split applies to temporary: `302` (legacy, may rewrite to GET) vs `307` (preserves method).
search: unauthorized forbidden
401 Unauthorized — request lacks valid authentication. Server must return a WWW-Authenticate header. Despite the name, this is really "Unauthenticated". 403 Forbidden — request is authenticated but the principal is not allowed to perform this action. No WWW-Authenticate; retrying with different credentials won't help unless permissions change.
The naming is unfortunate — `401` is about authentication (who are you?) and `403` is about authorization (what can you do?). A common pattern: return `401` when the auth token is missing or expired (client should re-login), `403` when the token is valid but lacks scope (client should request elevated permissions). Some APIs use `404` instead of `403` to avoid leaking the existence of resources to unauthorized callers.
Codes are sourced from the IANA HTTP Status Code Registry, which is the official authority. The current core definitions live in RFC 9110 (HTTP Semantics, June 2022), with extensions in RFC 9111 (Caching) and topic-specific RFCs like 7538 (308 redirect), 6585 (precondition required, too many requests), and 8297 (early hints). Each row links to the section that defines it so you can verify against the spec.
The registry is permissive — anyone can request a code allocation through the IETF process. Some codes are common (`200`, `404`, `500`); others are niche (`418 I'm a teapot` from an April Fools RFC, `451 Unavailable For Legal Reasons` named after Fahrenheit 451). Some address narrow protocols (WebDAV adds 207 / 422 / 423 / 424 / 507 in RFC 4918). The reference shows all of them so you can recognize them when they appear in a CDN log or a third-party API.
Legal but misleading. HTTP status codes communicate to *infrastructure* — load balancers, retry libraries, cache layers, monitoring dashboards. Sending `200` for what is logically a failure tells the CDN to cache the error response, the retry library to consider the call successful, and the on-call dashboard to plot it as a green dot. Reserve `2xx` for actual success; use `4xx` for client errors and `5xx` for server errors so the surrounding ecosystem treats them correctly. GraphQL is the main exception — its spec returns `200` with errors in the body because the protocol layer is HTTP-agnostic.
Two of them are. `100 Continue` is used by HTTP/1.1 clients with `Expect: 100-continue` to ask the server if a large request body is welcome before sending it; most servers handle this transparently. `103 Early Hints` (RFC 8297, 2017) lets the server send preload hints for CSS / JS before the actual `200` response is ready — Cloudflare and Fastly support it. The rest (`101 Switching Protocols` for WebSocket upgrade, `102 Processing` for WebDAV) are protocol-specific. Day-to-day API development rarely sees 1xx.
All three are upstream / gateway failures, but from different angles. **`502 Bad Gateway`** — the proxy got a *broken* response from the upstream (connection reset, malformed HTTP). **`503 Service Unavailable`** — the server itself is unable to handle the request (overload, maintenance, graceful shutdown); should include `Retry-After` header. **`504 Gateway Timeout`** — the proxy waited for the upstream and timed out. In an nginx → app stack: `502` is "app crashed", `503` is "app said `I am full`", `504` is "app took too long to answer". The right code helps on-call know whether to restart, scale, or investigate latency.
Technically no — the IANA registry is the source of truth and proxies, browsers, and middleware may treat unregistered codes as their class default (any 4xx behaves like 400, any 5xx like 500). In practice frameworks tolerate it as long as the first digit is meaningful, and some private APIs use unregistered codes like `419 Authentication Timeout` (Laravel) or `420 Method Failure` (deprecated Twitter API). For new public APIs stick to registered codes and put detail in the response body — clients ignore unknown codes uniformly enough that the extra information value is small.
HTTP status codes are 3-digit integers that the server returns alongside the response. The first digit identifies the **class**: `1xx` informational (rare, protocol-specific), `2xx` success, `3xx` redirection, `4xx` client error, `5xx` server error. RFC 9110 (June 2022) consolidated the previous status-code definitions from RFC 7231 / 7232 / 7233 / 7234 / 7235 into a single document and is the current normative reference. The IANA HTTP Status Code Registry holds the authoritative list of allocated values.
The semantic difference between adjacent codes matters more than people expect. `200` and `204` both say "success" but `204` carries no body — clients should not parse one. `201` confirms creation and the response carries the new resource's representation or a `Location` header. `301` and `308` are both "permanent redirect" but `308` preserves the HTTP method; `301` historically rewrites POST to GET. `409 Conflict` and `422 Unprocessable Content` both mean "I refused your write" but `409` is for state conflicts (concurrent edits, duplicate key) and `422` is for validation failures (bad email format). Picking the right code is signaling, not pedantry — caches, retry libraries, and observability tools all react to the code without reading the body.
Three adjacent concepts shape day-to-day API design. **Idempotency** classifies methods (`GET`, `PUT`, `DELETE` are idempotent; `POST` is not) and decides safe retry behavior; status code design works alongside this so a client knows whether to retry on `503`. **Caching** (RFC 9111) determines which responses get stored — `200`, `203`, `204`, `300`, `301`, `404`, `405`, `410`, `414`, `501` are cacheable by default; others need explicit headers. **Content negotiation** uses headers like `Accept`, `Accept-Language`, and returns `406 Not Acceptable` when none of the offered representations match. Status codes sit in the middle of all three, which is why getting them right pays off across the stack.
Paste a curl command and get the equivalent fetch, axios, Go net/http, and Python requests snippet. Handles -X, -H, -d / --data, -u, --form, and multiline backslash continuation.
Format and validate JSON. Indented or minified output, with clear error messages.
Encode text to Base64 or decode Base64 back to text. UTF-8 safe.
Percent-encode or decode URL components.
Initial part of request received; continue with the rest.
Server is switching protocols per Upgrade header (e.g., HTTP → WebSocket).
WebDAV: request being processed; no response yet.
Hint at resources the client can start fetching while final response is prepared.
Request succeeded; semantics depend on the method.
New resource created — typically returned by POST.
Request accepted but not yet processed (async work).
Response was modified by a transforming proxy.
Success, but no body — used for DELETE and idempotent updates.
Tell the client to reset the document view (e.g., clear a form).
Partial response per Range header — used for resumable downloads and streaming.
WebDAV: multiple status codes inside the body (XML).
WebDAV: members already enumerated in a previous reply.
Delta encoding: server fulfilled the request using one or more instance-manipulations.
Resource has multiple representations; client picks one.
Resource permanently moved to a new URL — update bookmarks and links.
Temporary redirect — the request method may change in practice.
Tells client to GET the resource at a different URL — POST/Redirect/GET pattern.
Cached response is still valid; no body sent.
Like 302 but preserves the request method.
Like 301 but preserves the request method.
Malformed syntax, invalid framing, or a request the server cannot understand.
Authentication required or failed — see the WWW-Authenticate header.
Reserved for paid resources; rarely used in practice.
Authenticated, but access is denied for this resource.
No resource at that URL — by far the most common error.
Method not supported for this resource — see the Allow header.
Server cannot produce a response matching the Accept-* headers.
Like 401 but for the proxy in front of the server.
Server closed the connection because the request was too slow.
Request conflicts with current resource state (e.g., concurrent edit).
Resource permanently removed — no forwarding URL.
Content-Length header is required for this request.
If-Match / If-Unmodified-Since condition not satisfied.
Request body exceeds server limits (previously Payload Too Large).
URL longer than the server accepts.
Content-Type not supported for this endpoint.
Requested Range cannot be returned (e.g., past the end of file).
Server cannot meet the Expect header requirement.
April Fools joke (RFC 2324). Returned by some sites for impossible requests.
Request sent to a server that cannot answer for this hostname/authority.
Request is syntactically OK but semantically invalid — common for form validation.
WebDAV: resource is locked.
WebDAV: a prior request in a multi-request chain failed.
Server is unwilling to process a request that may be replayed.
Client must switch protocols (see the Upgrade header).
Server requires the request to be conditional — protects against lost-update.
Rate-limited — see the Retry-After header.
Total request headers exceed server limits.
Blocked due to legal demand — name is a Fahrenheit 451 reference.
Generic server-side failure — typically a bug or unhandled exception.
Server does not support the request method.
Upstream server returned an invalid response to a proxy.
Server is overloaded or down for maintenance — try later.
Upstream server timed out before responding to a proxy.
HTTP version in the request is unsupported.
Content negotiation loop detected on the server.
WebDAV: server out of storage for the request.
WebDAV: infinite loop detected while processing.
Server requires further extensions to fulfill the request.
Client must authenticate to gain network access (captive portals).