HTTP Status Codes

Reading a status code

HTTP status codes are the three-digit numbers a server returns to a client to communicate the outcome of a request. They're grouped into five families: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), and 5xx (server error). Most developers know the common codes — 200, 301, 404, 500 — but the specification defines dozens more, and choosing the right one matters for API reliability, SEO, client behaviour, and debugging. This tool gives you the complete reference: meaning, use case, and the RFC where each code is formally defined.

Logs, API design, and production debugging

• Reading API documentation or error logs and encountering an unfamiliar code (425? 451? 308?) — look it up in seconds.
• Designing your own API and deciding which status code to return — 404 vs 410, 401 vs 403, 422 vs 400, 200 vs 201.
• Debugging production issues: a 502 Bad Gateway usually means the upstream is down or unreachable, while 504 Gateway Timeout suggests it's responding too slowly.
• Reviewing code or design documents and needing the authoritative RFC reference to back up your choice.
• Deciding whether to return a 2xx status with an error object in the body, or a proper 4xx/5xx — they have different semantic meanings and client implications.
• Understanding why a third-party service is returning an unexpected code and what you should do about it.

Searching and filtering by class

• Type or paste a status code (e.g. 429, 503) into the search box, or scroll the full list.
• Filter as you type — results narrow down instantly across code number, name, and description.
• Click any result to see the full details: plain-English meaning, typical causes, and the relevant RFC (usually RFC 9110 for modern codes).
• Use the family groupings (1xx, 2xx, 3xx, etc.) to browse codes by category if you're exploring or learning.
• Reference the RFC link for the normative specification if you're writing specs or need legal/formal wording.

Codes that trip up even experienced developers

• 401 vs 403 — 401 means "I don't know who you are" (unauthenticated); 403 means "I know who you are and you're not allowed" (unauthorised). Only use 403 if authentication alone wouldn't fix the problem.
• 302 vs 307 vs 303 — A 302 redirect is ambiguous: browsers may change POST to GET (a legacy quirk). Use 307 to preserve the original method, or 303 to explicitly require GET. Be explicit in new APIs.
• 404 vs 410 — 404 means "not found right now, might come back"; 410 means "gone permanently, remove from indices". Search engines treat 410 as a deletion signal; use it when you're retiring a resource.
• 200 with error body — Returning HTTP 200 with an error message in the JSON body is not RESTful and breaks client expectations. Return the appropriate 4xx or 5xx with the error in the body instead.
• 418 I'm a teapot — This is an April Fools' RFC joke (7168). Don't use it in production; some clients and proxies handle it unpredictably.
• RFC 9110 is current — RFC 9110 (June 2022) supersedes the older RFCs 7231–7235. Cite 9110 unless you have a reason to reference an older spec.

1xx through 5xx at a glance

• 1xx (Informational) — Server is still processing. Rarely seen by end users; mostly used for 100 Continue in request/response negotiation.
• 2xx (Success) — Request succeeded. 200 (OK), 201 (Created), 204 (No Content), and 206 (Partial Content) are the most common.
• 3xx (Redirection) — Client must take further action. Includes redirects (301, 302, 307, 308), caching directives (304), and special cases (307, 308).
• 4xx (Client Error) — Client's fault: bad syntax, auth failure, resource not found, rate limiting. Server should not retry.
• 5xx (Server Error) — Server's fault: internal error, not implemented, gateway trouble, overloaded. Client may retry (especially 503, 504).

RFC lineage and the search interface

Every HTTP response opens with a three-digit status code, and the first digit is the whole story in miniature: 1xx informational (the request is still in flight), 2xx success, 3xx redirection, 4xx the client got something wrong, 5xx the server did. The class-filter buttons narrow the table to one band at a time, and the search box matches on the number or the text — type 404, or type gateway to surface 502 and 504 together. Each row gives the reason phrase, the practical cause, and the defining RFC.

Most core codes now trace back to RFC 9110 (HTTP Semantics, 2022), which consolidated the older RFC 2616 / 7230–7235 series — so a modern citation reads "RFC 9110 §15.x" rather than the scattered references you'll still see in older docs. Specialist codes keep their own RFCs: 429 and 431 from RFC 6585, 451 from RFC 7725, the WebDAV range (207, 422, 423…) from RFC 4918.

Choosing between similar codes

401 or 403 — what's the difference? 401 Unauthorized actually means unauthenticated: you haven't proven who you are, and a login challenge should follow. 403 Forbidden means you're authenticated but not allowed — a login prompt won't help, so don't send one.

Which redirect should I return — 301, 302, 307 or 308? Use 301/308 for permanent moves and 302/307 for temporary ones. The modern pair (307/308) explicitly preserves the request method and body; the legacy pair (301/302) historically let clients silently turn a POST into a GET. If a POST must stay a POST across the redirect, pick 307 or 308.

400 or 422 for a bad request body? 400 Bad Request is for malformed syntax the server can't even parse (broken JSON, a missing required header). 422 Unprocessable Content is for a body that parses fine but fails your validation rules — right shape, wrong values.

Which 5xx should a reverse proxy return? 502 Bad Gateway when the upstream replied with garbage, 504 Gateway Timeout when it didn't reply in time, and 503 Service Unavailable when you're deliberately down or overloaded — pair 503 and 429 with a Retry-After header so clients back off sensibly.