HTTP Status Reference

HTTP Status Reference is a searchable, color-coded directory of the response codes you actually meet in logs and APIs. Instead of paging through specification text, you can look up what 307 or 429 means in seconds. It serves developers debugging a failing endpoint, operations engineers reading proxy logs, and anyone writing error handling that needs to branch on the right code.

What the Reference Actually Lists

The list is deliberately curated rather than exhaustive. It holds 38 codes, and knowing the set prevents confusion when a code you expect is absent.

Class	Count	Codes included
1xx	4	100, 101, 102, 103
2xx	7	200, 201, 202, 203, 204, 205, 206
3xx	7	300, 301, 302, 303, 304, 307, 308
4xx	15	400, 401, 403, 404, 405, 408, 409, 410, 413, 414, 415, 418, 422, 429, 451
5xx	5	500, 501, 502, 503, 504

Notable gaps include 305 Use Proxy and 306, 402 Payment Required, the remaining 4xx codes such as 406, 407, 411, 412, 416, 417, 426, 428 and 431, and every 5xx above 504. The reference describes common behavior, not the complete IANA register.

Searching and Filtering

The search box accepts three kinds of query. A complete three-digit number is matched exactly, so 404 returns only Not Found. A shorter digit string matches as a prefix, so 40 lists all seven codes beginning with 40 and 5 lists the five server errors. Anything else is matched case-insensitively against both the code name and its description, so teapot finds 418 and rate finds 429.

The category tabs work alongside search rather than replacing it. Selecting 4xx restricts the list to client errors, and typing in the search box then narrows that subset further. Picking a category clears the unsearched codes, which makes it easy to scan one class in isolation.

The Codes People Confuse

401 vs 403. 401 Unauthorized means the request lacks valid authentication credentials; 403 Forbidden means the credentials are understood but do not grant access. Sending 403 when the client simply has not logged in leaks less information but misleads the caller.

301 vs 302. 301 is a permanent move and tells crawlers and browsers to update their records. 302 is temporary and preserves the original URL for future requests. The sibling codes 307 and 308 mean temporary and permanent redirect that preserve the original HTTP method, unlike 301 and 302, which historically allowed method changes.

502 vs 503 vs 504. All three come from an intermediary or an overloaded origin. 502 is a malformed upstream response, 503 is a deliberate refusal, and 504 is a timeout. The Retry-After header is most meaningful on 503 and 429.

204 vs 200. 204 No Content confirms success with an empty body, which is common after a DELETE. Returning 200 with an empty body is legal but less precise.

Where the Codes Come From

The core codes are defined by the HTTP semantics specification and related documents. A few entries carry specific provenance: 102 Processing and 422 Unprocessable Entity are WebDAV extensions, 103 Early Hints supports preloading, 451 Unavailable For Legal Reasons was added for legally blocked content, and 418 traces to an April Fools RFC. The reference notes these origins in the descriptions so you can distinguish standards work from extensions and jokes. Because the set is curated, a code that appears in the IANA registry but not here is not necessarily invalid; it is simply outside the day-to-day list this page maintains.

Reading a Response in Context

When you see a status code, the useful next question is who owns the fix. A 4xx belongs to the caller: change the request, add credentials, slow down, or correct the body. A 5xx belongs to the server or its operators: retry later, check the upstream service, or inspect logs. That single split tells you whether a retry loop makes sense.

Method and semantics matter as well. A successful DELETE is often better expressed as 204 No Content than 200 with an empty body, and a 201 Created should come with a Location header pointing at the new resource. A 405 Method Not Allowed should list acceptable methods in an Allow header, and a 429 should carry Retry-After. Those header hints are not part of the reference, but they are part of using each code correctly.

The code is also only half of the contract. Headers and cached state carry meaning too. A 304 Not Modified is a caching success, not an error, and a 3xx that a browser follows automatically may look like a 200 by the time client code observes it.

Common Mistakes

Returning 200 with an error message in the body, which breaks every client that checks the status code. Using 302 for a permanent move and then losing accumulated search signals. Treating 401 as “not allowed” and using it where 403 belongs, or the reverse. Retrying a 4xx blindly: a 400, 401, or 422 will not succeed until the request changes. And using 500 for anything unexpected when a more specific 502, 503, or 504 would point at the real cause.

Related Tools

• URL Encoder
• JSON Formatter
• Base64
• User Agent Parser
• MIME Type Lookup