HTTP Status Codes: searchable 1xx–5xx reference for every response
Live HTTP status checker plus a complete, searchable index from the IETF — paste any URL to see its real status code, or browse 200 OK, 301 redirects, 401, 404, 500 and every other 1xx–5xx response. Filter by category, search by number or name, and copy the line you need.
Fetches the URL through a CORS proxy and shows the final status code. Tap the badge to scroll to its entry in the reference below. Need every hop in a redirect chain? Use the Redirect Checker.
Cheat-sheet at a glance
The five classes encode intent before you read the body. Get the first digit right and clients can branch on the response without inspecting the payload.
200 OK 201 Created 204 No Content 206 Partial Content
400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 422 Unprocessable Entity 429 Too Many Requests
What you'll use this for
Status codes are a tiny vocabulary that every browser, proxy, and crawler already understands. Use the right one and you get correct caching, retries, and SEO behaviour for free.
API design
Pick a code that matches the failure mode — clients and SDKs know how to handle it without reading prose.
Debugging
You see a 405 in your logs. What does it actually mean? Look it up in two keystrokes, ship the fix.
Writing docs
Drop the canonical name and one-liner straight into your OpenAPI spec or README.
Error monitoring
Annotate dashboards with what each spike of 502s or 429s actually represents.
How to use this reference
Type a number or word
The search box matches the code, the name, or the description. 418, teapot, and I'm a all surface the same row.
Or filter by class
Click a category pill to narrow to 2xx, 4xx, or any of the five classes. Combine with search to narrow further.
Copy what you need
Per-row copy buttons drop code name straight onto your clipboard for use in docs, logs, or PRs.
Bulk export
Hit Download .txt to grab the entire filtered list — handy for code review checklists or onboarding.
Frequently asked questions
301 Moved Permanently tells clients and search engines to update bookmarks and link equity to the new URL. 302 Found (and the stricter 307 Temporary Redirect) say the move is temporary — the original URL stays canonical and clients should keep using it for future requests.
400 Bad Request is for syntactically invalid requests — malformed JSON, missing required headers, garbled query strings. 422 Unprocessable Entity (RFC 4918, brought into HTTP proper by 9110) is for syntactically valid payloads that fail semantic validation — for example, an email field that parses fine but isn't a real address.
451 Unavailable For Legal Reasons. The number is a nod to Fahrenheit 451 and signals that the resource is blocked by a government order, court demand, or other legal mandate — distinct from 403 (server-chosen denial) or 404 (does not exist).
Yes and no. 418 I'm a teapot comes from RFC 2324, an April Fool's joke about Hyper Text Coffee Pot Control Protocol. It's not part of HTTP itself, but it's reserved by IANA and ships in real frameworks because removing it would break joke endpoints worldwide.
RFC 8297 introduced 103 Early Hints for sending Link headers before the final response, letting clients begin preloading critical assets. It's the most recently standardised addition, and modern CDNs increasingly use it to shave milliseconds off page loads.
About HTTP status codes
HTTP status codes are three-digit integers returned by servers to summarise the outcome of a request. The first digit divides the 100 possible numbers into five well-defined classes; the second and third digits identify the specific condition. The canonical references are RFC 9110 (HTTP semantics) plus extension RFCs for WebDAV, rate limiting, and legal blocking.
The five classes
- 1xx Informational — request received, continuing. Rare to see in browser logs.
- 2xx Success — the request was understood, accepted, and processed.
- 3xx Redirection — further action is needed (usually following a
Locationheader). - 4xx Client Error — the request was malformed, unauthorised, or otherwise can't be satisfied.
- 5xx Server Error — the server tried but failed to fulfil a valid request.
Practical tips
- Use 201 Created with a
Locationheader when your POST creates a new resource. - Use 204 No Content when a successful action has no body to return (e.g. DELETE).
- Use 429 Too Many Requests with a
Retry-Afterheader for polite rate limits. - Reserve 500 for genuine internal errors — don't shovel client-side failures into it.