Status Code Tester

Look up any status code number across all 7 protocols. See what 200, 404, or 503 means in HTTP, gRPC, SIP, and more.

Try: 200, 404, 503, timeout, redirect, auth...

No matching status codes found.

results across protocols

How to Use

  1. 1
    Enter a status code number

    Type any numeric status code (100–599) into the search field. The tool searches across HTTP, WebDAV, WebSocket, CoAP, FTP, SMTP, and RTSP protocol registries simultaneously.

  2. 2
    Read the protocol-specific meaning

    Each protocol may assign a different meaning to the same numeric code. Review the description, RFC reference, and whether the code is a standard, unofficial, or deprecated entry.

  3. 3
    Copy for use in your API or docs

    Use the copy button to grab the code, its canonical name, and RFC citation for inclusion in API documentation, error handling code, or runbooks.

About

HTTP status codes are three-digit integers that servers return to signal the outcome of a request. Grouped into five classes — 1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Error, and 5xx Server Error — they form the machine-readable backbone of the web. RFC 9110 (HTTP Semantics, published June 2022) supersedes RFC 7231 as the canonical reference, consolidating the semantics of all registered HTTP status codes and clarifying long-standing ambiguities around idempotency and safe methods.

Beyond HTTP, the same numeric space is used across seven major protocols including WebDAV (RFC 4918), RTSP (RFC 7826), CoAP (RFC 7252), FTP (RFC 959), SMTP (RFC 5321), and WebSocket (RFC 6455). While the 200-level success and 400/500-level error conventions are broadly shared, individual codes carry protocol-specific meanings. FTP 530 means Not Logged In while HTTP 530 is an unofficial Cloudflare-specific code for blocked requests. Understanding the protocol context is essential for correct interpretation.

The Status Code Tester aggregates IANA-registered codes, RFC-backed extensions, and widely-used unofficial codes into a single searchable reference. Each entry links to its authoritative RFC, notes whether the code is standard, experimental, or deprecated, and indicates which protocols assign it a meaning. This makes it the authoritative lookup for API designers, backend engineers, and anyone writing HTTP client error-handling logic.

FAQ

Why does 422 mean something different in HTTP vs WebDAV?
HTTP 422 Unprocessable Content (defined in RFC 9110 §15.5.21, originally from WebDAV RFC 4918) entered mainstream HTTP to signal that a request body is syntactically valid but semantically incorrect — for example, a JSON payload that passes schema validation but contains a logically impossible date range. WebDAV uses it within its broader set of multi-status responses. The same numeric space (400–499) is shared across protocols, but registrations are managed separately by IANA.
What is the difference between 301 and 308 redirects?
Both indicate a permanent redirect, but they differ in method preservation. RFC 7238 defines 308 Permanent Redirect to guarantee that the HTTP method (POST, PUT, etc.) is preserved in the redirected request. A 301 redirect historically caused many clients to downgrade POST to GET. Use 308 for API endpoints that accept POST data and must be permanently relocated. Google Search treats both equivalently for PageRank transfer.
When should an API return 409 Conflict versus 422 Unprocessable Content?
RFC 9110 §15.5.10 defines 409 Conflict for state conflicts — the request cannot be processed because it conflicts with the current resource state, such as trying to create a duplicate unique resource or editing a stale version (optimistic concurrency). Use 422 when the request body is structurally and syntactically valid but semantically wrong, such as submitting a checkout with an out-of-stock item. 409 is about resource state; 422 is about business logic violations.
What does 425 Too Early mean and when was it added?
RFC 8470 introduced 425 Too Early to address a TLS 1.3 security concern with 0-RTT (zero round-trip time) data. When a client sends data in the first TLS flight before the handshake completes, a replay attacker could duplicate that request. The server responds with 425 to indicate the request should be retried after the handshake, preventing replay attacks on non-idempotent operations like payments.
Are there HTTP status codes not registered with IANA?
Yes. Unofficial codes like 418 I'm a teapot (RFC 2324, an April Fools' joke), 420 Enhance Your Calm (Twitter), and 450 Blocked by Windows Parental Controls (Microsoft) exist in the wild but are not in the IANA HTTP Status Code Registry. RFC 9110 §16.2 governs the official registry. Some codes like 419, 449, and 509 are vendor extensions with no RFC backing. This tool labels unofficial and vendor-specific codes distinctly from IANA-registered entries.