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. Search by number or status name, browse a class, and read a short description with practical usage notes. The list includes common IETF, WebDAV, and extension codes such as 422, 425, 429, and 308; it is a quick reference rather than an exhaustive registry of every extension code.

Why use it

• RFC-accurate definitions: Every entry cites the authoritative RFC section — no outdated or folk-wisdom descriptions. Know exactly what the spec says, not what a Stack Overflow answer summarizes.

• 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.

• Covers rare and extension codes: Includes WebDAV codes (207, 422, 423), rate limiting (429), early hints (103), and processing (102) — not just the ten most common codes every tool covers.

• Correct vs incorrect usage notes: Many codes are routinely misused — 400 vs 422 for validation errors, 403 vs 404 for authorization. The tool flags common misuse patterns so you pick the semantically right code.

• Fast during incidents: No network dependency, no login. When your monitoring dashboard shows a spike in 502s at 2 am, look it up instantly without waiting for a documentation site to load.

How to use

1. Type a numeric code (e.g. 404) or a status phrase (e.g. Unprocessable Entity) into the search field.
2. Results appear instantly as you type — select any match to expand the full detail card.
3. Read the plain-English meaning, the RFC citation, typical causes, and correct usage notes.
4. Use the class filter buttons (1xx, 2xx, 3xx, 4xx, 5xx) to browse all codes in a category.
5. Click the Copy button on any result card to copy a formatted status line (e.g. 404 Not Found) to your clipboard.
6. For API documentation work, use the share icon to get a direct URL to a specific status code page.

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 exact RFC language to cite in response-code tables or OpenAPI spec descriptions.
• 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, using real RFC definitions as the authoritative source.

Examples

Query: 429

429 Too Many Requests — the server is rate limiting the client; check Retry-After when present.

Query: unprocessable

422 Unprocessable Content — the request syntax is valid but the submitted data fails semantic validation.

Filter: 3xx Redirection

Browse the listed 3xx codes and their redirect behavior; 307 and 308 preserve the request method.

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.