HTTP Status Codes
A complete, searchable index of HTTP response status codes from the IETF — every entry covers the canonical name, response class, and a short description of when servers should send it. Filter by category, search by number or word, and copy the line you need.
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.