Complete HTTP status code reference: all 1xx/2xx/3xx/4xx/5xx codes with names, descriptions, and use cases. Searchable and filterable, links to MDN docs.
TL;DR: Free HTTP status codes reference covering all 1xx-5xx codes with descriptions and usage scenarios. Fully offline, no registration required.
For local tools, open DevTools → Network and search your input — it should not appear in requests.
Usage Guide
HTTP status codes are the server's first signal: three digits in five families, and reading the first digit gets you most of the way. This page is a searchable cheat sheet — common-code chips, category filters, keyword search, and a copyable response example (status line + headers + sample body) on every row.
1. Fastest way to look a code up
- Common status code chips: tap 200 / 401 / 404 / 429 / 502 to fill the search box and clear the category filter.
- Category tabs: narrow to 1xx–5xx, then search by number, English name, or description keyword (teapot, rate limiting).
- Copy response example: the copy icon builds a status line + key headers + sample body (Location on 201, Retry-After on 429, empty body on 204).
- Open the external-link icon for the MDN page when you need the normative details.
2. The five families in one line each
- 1xx informational: received, continue (101 protocol switch is the WebSocket handshake step).
- 2xx success: 200 is the workhorse; 204 means success with no body, common for deletes.
- 3xx redirect: 301 permanent (search engines move ranking), 302 temporary, 304 conditional-cache hit — the backbone of browser caching.
- 4xx client error: 401 unauthenticated (no credentials or expired token), 403 authenticated but forbidden, 404 no such path, 429 too many requests.
- 5xx server error: 500 internal exception, 502 gateway got an invalid upstream response, 504 upstream timed out — 502/504 almost always mean the service behind the reverse proxy is the problem.
3. The three distinctions that matter most when debugging
401 vs 403: 401 says "I do not know who you are" (retry with credentials); 403 says "I know who you are and you still cannot" (retrying is futile). 502 vs 504: 502 means the upstream answered with garbage or disconnected; 504 means it said nothing within the timeout — check upstream crashes for the former, upstream performance for the latter. 301 vs 302: use 301 for domain moves and path changes to carry SEO weight, 302 for temporary campaigns — swapped, search engines will treat the temporary page as the permanent home. Prefer 307/308 for APIs so older clients do not silently rewrite POST to GET.
FAQ
All five RFC families: 1xx informational, 2xx success, 3xx redirection, 4xx client errors, and 5xx server errors, each with a plain-language description and typical usage scenarios.
401 Unauthorized means unauthenticated — a login or valid credentials are required. 403 Forbidden means the request is authenticated but lacks permission for the resource. In short: 401 asks "Who are you?", 403 says "You cannot come in".
Yes. Search by status code number or keyword, or filter by the five families; once you land on an entry, its sample response snippet can be copied straight into a mock or an error handbook.
The table gives you the standard semantics as a starting point; what a code means in your product is decided by your API conventions. Do not grab a "close enough" code — confirm key decisions against your project tests and docs.
No. The status code data ships inside the page itself, so search and filtering keep working even when you are offline.
Related Tools
Related Articles
HTTP Status Codes Reference: Quick Lookup Guide
Complete HTTP status code reference. Understand 1xx, 2xx, 3xx, 4xx, 5xx categories, common scenarios, and correct usage in API development.
What Is a CORS Preflight Request (OPTIONS)? A Cross-Origin Mechanism Every Frontend Developer Must Know
What is a CORS preflight? How simple requests differ from preflight, what Access-Control-Allow-* headers mean, credentials rules, common pitfalls, and how to use this site's API Tester in direct vs proxy mode.
Incomplete HTTPS Certificate Chain: Browser Distrusts a “Valid” Leaf
Leaf dates and SAN look fine, but clients still reject the cert? Usually a missing intermediate or misordered fullchain. Verify Issuer→Subject with openssl s_client and a local decoder.