Search common or registered HTTP status codes with RFC semantics, response examples, related codes, pitfalls, and an explicit API-contract handoff.
Choose your path
Find and expand one HTTP response status reference from a compact common-code set or explicit search, then consult the current IANA registry and governing RFC before implementing application behavior.
Locate the relevant code and distinguish its protocol meaning from an application error contract.
Search by code/name/description, expand the reference, follow IANA/RFC sources and save the selected observation.
Implements the code with headers, body, caching and method semantics reviewed separately.
Quickly decode a received code without scanning hundreds of entries.
Use the nine-code quick reference or category filter, expand the exact match and compare it with server/proxy evidence.
Gets a concise starting point without treating the page as root-cause diagnosis.
Verify authority freshness, compact initial density and operable disclosure controls.
Inspect IANA/RFC links, match count, category/search/expand semantics and narrow-screen layout.
No invented registry status, unnamed disclosure, excessive first view or horizontal overflow remains.
Outputs and checklists are planning aids. Review the linked current authorities and the records, terms, instructions, and requirements that apply to your exact situation before a consequential decision.
This tool is part of these guided projects. Each project provides step-by-step instructions with checklists and all the tools you need in one place.
Tools you might need next
Parse HTTP header blocks into ordered JSON with duplicate fields intact, default sensitive-value redaction, line errors and protocol-review warnings.
Test ECMAScript regular expressions with exact global, Unicode, capture, index, and replacement behavior plus conservative backtracking-risk refusal.
Validate RFC 8259 JSON syntax with line hints, duplicate-member and precision warnings, plus an explicit schema and API-contract boundary.
Search matches code, reason phrase, description and use cases; class filters narrow 1xx–5xx responses. The initial catalog is intentionally reduced to common codes.
Each expandable record separates a short working description, defining-RFC context, example response, related codes and common pitfalls instead of presenting a code as a complete policy.
IANA and RFC links remain visible in the task surface. Project saving requires one expanded code and never claims that the endpoint contract or runtime behavior has been verified.
Updated: August 2026
An API designer compares 401, 403 and 404 semantics, expands the chosen response, and records the bounded rationale without inferring authorization behavior.
A developer reviews 202 and related responses, then documents polling, completion representation and failure behavior outside the status-code selection itself.
A reviewer compares temporary and permanent redirect semantics and separately verifies Location and cache policy against RFC 9110 and RFC 9111.
Start with nine common responses, search by code or meaning, filter by class, then expand one reference. The panel links to IANA and RFC 9110 and records only an explicitly selected code in the REST API Project.