HTTP Status Lookup

About this tool

HTTP Status Lookup searches a curated set of 32 commonly used HTTP response codes from the 1xx through 5xx classes. Type a number or part of a status name, or filter by class, and the first match is shown with its class, category and a one-line common-use note; click any code in the Matches list to show it instead. The list includes common codes plus a few extensions such as 102 Processing, 103 Early Hints, 422 Unprocessable Content and 429 Too Many Requests. It is a quick reference rather than an exhaustive registry, and it does not quote RFC text.

Why use it

• Short, practical notes: Every entry has a one-line common-use note, such as 'Temporary redirect that keeps method/body.' for 307, so you can confirm the meaning at a glance.

• Search by code or phrase: You rarely remember both the number and the name at once. Search either direction — '503' or 'service unavailable' — and land on the same result.

• Class-level browsing: During incident triage or API design, browse all 4xx client errors or all 5xx server errors at once with the class filter to quickly identify the right code to return.

• Focused list: 32 high-frequency codes, including 102 Processing, 103 Early Hints, 422 and 429, keep results short and easy to scan.

• Number prefix search: Typing 50 lists 500 to 504, and typing 4 lists every 4xx code, which is handy when you only remember the first digits.

• Fast during incidents: No network request per lookup, no login. When your monitoring dashboard shows a spike in 502s at 2 am, look it up instantly.

How to use

1. Type a numeric code (e.g. 404) or part of a status name or note (e.g. unauthorized) into the search field.
2. Results update as you type — the first match appears in the Result box and every match is listed as a button under Matches.
3. Click any code button under Matches to show that code's class, category and common-use note.
4. Use the class filter buttons (All, 1xx, 2xx, 3xx, 4xx, 5xx) to browse all codes in a category.
5. Click Copy result to copy the shown entry (code, name, class, category and common use) to your clipboard.

When it helps

• Debugging API responses during development when an unfamiliar status code appears in the network panel and the meaning is not immediately obvious.
• Designing REST or GraphQL API error responses and needing to choose the semantically correct code (e.g. 400 vs 409 vs 422) for a given failure scenario.
• Writing API documentation and needing the standard reason phrase for each code in a response-code table.
• Triaging production incidents where logs show unexpected status codes from upstream services, CDNs, or load balancers.
• Reviewing a pull request that changes error handling and wanting to verify the proposed codes match their intended semantics.
• Teaching HTTP fundamentals to junior developers or in a team workshop by browsing each status class.

Examples

Query: 429

429 Too Many Requests
Class: 4xx
Category: Client Error
Common use: Rate limit exceeded; retry after waiting.

Query: unprocessable

422 Unprocessable Content
Class: 4xx
Category: Client Error
Common use: Well-formed request but semantic validation failed.

Filter: 3xx

6 matches: 301 Moved Permanently, 302 Found, 303 See Other, 304 Not Modified, 307 Temporary Redirect, 308 Permanent Redirect

Tips

• For REST APIs, prefer 422 over 400 for field-level validation errors and include a structured error body listing which fields failed — this lets clients display form errors without re-parsing a generic message.
• Return 503 with a Retry-After header during planned deployments or maintenance windows so monitoring systems and clients back off gracefully instead of flooding logs with errors.
• Never return 200 with an error payload (a so-called '200 OK with error in body') — it breaks HTTP-layer monitoring, CDN caching, and client error-handling logic.
• Use 304 Not Modified responses with ETag or Last-Modified to enable conditional GET caching — this dramatically reduces bandwidth for API clients that poll frequently.
• For security-sensitive endpoints, consider returning 404 instead of 403 when a resource exists but the caller is unauthorized — this avoids leaking information about resource existence to attackers.

Frequently Asked Questions

Glossary

HTTP status code

A three-digit integer returned in the first line of an HTTP response that indicates the result of the request. Codes are grouped into five classes by their first digit: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error.

RFC 9110

The 2022 IETF RFC that replaced RFC 7230–7235 as the authoritative specification for HTTP semantics, including the canonical definitions of all standard status codes. Supersedes RFC 7231.

Idempotency

A property of HTTP methods meaning repeated identical requests produce the same server state as a single request. GET, PUT, DELETE, and HEAD are idempotent; POST and PATCH generally are not. Status codes like 409 Conflict are relevant when idempotency invariants are violated.

Retry-After header

An HTTP response header sent with 429 (Too Many Requests) or 503 (Service Unavailable) that tells the client how long to wait before retrying — expressed as a number of seconds or an HTTP-date string.

Content negotiation

The HTTP mechanism where a client advertises acceptable response formats via Accept headers and the server returns 406 Not Acceptable if it cannot satisfy the request. Relevant to API design when returning structured error bodies.

WebDAV

Web Distributed Authoring and Versioning — an extension to HTTP defined in RFC 4918 that adds collaborative editing methods (PROPFIND, LOCK, UNLOCK) and introduces status codes 207, 422, 423, and 424 used in some REST APIs.