UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

HTTP Status Lookup

Search HTTP status codes and names with class-based filters and notes.

About HTTP Status Lookup

HTTP Status Lookup is a comprehensive reference for every standardized HTTP response code defined across IETF RFCs, from the informational 1xx class through the server-error 5xx class. Search by numeric code (e.g. 429) or by phrase (e.g. "Too Many Requests") and get an instant explanation of what the status means, which RFC section defines it, typical causes, and common correct and incorrect usage patterns. The tool covers all 63 codes in RFC 9110 plus extensions from RFC 6585 (rate limiting), RFC 7538 (308), RFC 8470 (425), and WebDAV (207, 422, 423, 424). Grouped filtering by 1xx, 2xx, 3xx, 4xx, and 5xx lets you browse a whole class during incident triage. Everything runs in the browser with no external requests.

Why use HTTP Status Lookup

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 HTTP Status Lookup

  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 to use HTTP Status Lookup

  • 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

Search by numeric code

Input: Query: 429

Output: 429 Too Many Requests — RFC 6585 §4. The user has sent too many requests in a given time. Inspect Retry-After header. Used for: rate limiting. Retryable: Yes.

Search by phrase

Input: Query: unprocessable

Output: 422 Unprocessable Entity — RFC 9110 §15.5.21. The request is well-formed but contains semantic errors. Used for: API input validation failures. Distinct from 400 (syntax errors).

Browse 3xx class

Input: Filter: 3xx Redirection

Output: 301 Moved Permanently, 302 Found, 303 See Other, 304 Not Modified, 307 Temporary Redirect, 308 Permanent Redirect — with method-preservation notes for each.

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

What is the difference between 400 Bad Request and 422 Unprocessable Entity?▾
400 means the server cannot parse the request at all — malformed JSON syntax, missing required headers, or invalid encoding. 422 means the syntax is valid but the semantic content fails validation — correct JSON but a field value is out of range or a required business rule is violated. RFC 9110 recommends 400 for syntax failures; RFC 4918 defines 422 for semantic/validation failures.
When should I use 401 versus 403?▾
401 Unauthorized means authentication is required or the provided credentials are invalid — the client should try again with valid credentials. 403 Forbidden means the server understood the request and the caller is authenticated, but they do not have permission to access the resource. Returning 404 instead of 403 is a common deliberate practice to avoid disclosing resource existence.
What does 301 vs 302 vs 307 vs 308 mean for redirects?▾
301 and 308 are permanent redirects; 302 and 307 are temporary. The key distinction between the pairs is method preservation: 301/302 historically allowed user agents to downgrade POST to GET on redirect; 307/308 require the original method to be preserved. Use 308 for permanent API endpoint moves where clients must re-POST to the new URL.
What is a 429 status and how should clients handle it?▾
429 Too Many Requests indicates a rate limit has been hit. Clients should inspect the Retry-After response header (seconds or HTTP date) before retrying. Immediate retry loops on 429 will worsen the situation. Well-behaved clients implement exponential backoff with jitter.
What does 503 Service Unavailable indicate and is it retryable?▾
503 means the server is temporarily unable to handle the request — typically due to overload or planned maintenance. It is always retryable. The server should include a Retry-After header if the downtime duration is known. Unlike 500, a 503 carries the implication that the condition is temporary.
Is 404 the right code when a resource once existed but has been permanently deleted?▾
410 Gone is the semantically correct code for a resource that existed and has been intentionally removed with no forwarding address. However, 404 is widely acceptable when you do not want to expose resource history. Use 410 when you want search engines to deindex the URL promptly — Googlebot treats 410 as a stronger removal signal than 404.
What is the 207 Multi-Status code used for?▾
207 is a WebDAV extension (RFC 4918) for responses that contain multiple independent operation results in the body — for example, a bulk operation where some items succeeded (200) and others failed (404 or 403). It is also used by some REST bulk-write APIs outside the WebDAV context.
Are all HTTP status codes covered, including unofficial ones?▾
The tool covers all codes defined in RFC 9110 (the 2022 HTTP core spec), RFC 9111, and commonly used extensions from RFC 6585, RFC 7538, RFC 8470, and RFC 4918 (WebDAV). Unofficial codes like 418 (I'm a Teapot, RFC 2324) and 420 (Enhance Your Calm, Twitter legacy) are included with appropriate context labels.

Explore the category

HTTP Headers Checker Inspect response status and headers from public HTTPS origins Website Status Checker Check whether any website or URL is up or down and see its HTTP response code, response time, and server headers. HTTP Request Builder Send HTTP requests from your browser via a server-side proxy — set method, headers, body, and inspect the full response. MIME Type Lookup Find MIME types from extensions and reverse-map MIME to extensions. DNS Lookup Tool Query public DNS records with SSRF-safe hostname validation JSON to CSharp Class Convert JSON payload samples into C# class models with inferred nested types.
HTTP Status Codes: The Complete Developer Reference Is that a 401 or a 403? A 404 or a 410? HTTP status codes have precise meanings that most developers only half-remember. Here is the definit Jan 2026 · 9 min Understanding HTTP Headers: A Developer's Reference HTTP headers carry critical information about authentication, caching, content type, and security — yet many developers only interact with t Feb 2026 · 10 min How HTTP Caching Works: Cache-Control, ETags, and Browser Storage HTTP caching is one of the most powerful and most misunderstood web performance tools. Getting Cache-Control right can eliminate most of you May 2026 · 10 min

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.