We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Provides developers and DevOps with complete definitions, category explanations, and RFC specification sources for HTTP status codes.
No data
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
This HTTP status code lookup presents a fixed table of selected response codes with a category, code number, name, description, and additional note. Use the table search to find a displayed number or term, sort a column to scan the entries, or move through the pages. It is a reference list rather than a live website checker: entering a domain or URL will not send an HTTP request or report whether a site is online.
HTTP response status codes are three-digit values from 100 through 599. Their first digit identifies the response class: 1xx informational, 2xx successful, 3xx redirection, 4xx client error, and 5xx server error. The class is useful context, but the code alone does not explain every server’s behavior or the cause of a particular response.
The built-in list contains selected common and historical entries; it does not mirror every value in the IANA registry. HTTP status codes are extensible, and additional codes can be registered or defined by other specifications. When a code is missing, consult the current IANA registry and its cited specification rather than inferring that the value is invalid.
Some wording in a static reference may reflect older terminology or an older description. The current HTTP semantics specification and registry are the authority for protocol meaning and current registration status. In particular, a table entry is a concise explanation, not a substitute for the full rule text.
Read the category first, then compare the code’s name and note. A 200 response is in the successful class, a 404 is in the client-error class, and a 500 is in the server-error class. These broad labels help orient troubleshooting, but a 404 does not by itself tell you whether a missing resource is temporary, and a 500 does not identify the underlying server fault.
When diagnosing an actual request, inspect the response headers, body, request method, and relevant application logs as well as the status code. A response can be generated by an origin server, proxy, gateway, or application layer, and the same code can appear in different situations.
Enter a number such as 404 or a word from a displayed name or description. The search filters the current reference rows.
Select a column heading to sort the table, then use the page controls to browse the displayed records.
For implementation or incident work, match the code to the current RFC or registry entry and read the specification section it cites.
Use the RFC for normative semantics and IANA for registration and references. A quick table is useful for orientation, but the response from your own request and the server’s logs provide the evidence needed to explain a live failure. This lookup does not test URLs, inspect response headers, or diagnose a server.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Use a known code or a term from the table. Search is limited to the records shown in this reference.
Use the class to orient the result, then read the description for the specific code. Do not treat a class label as a diagnosis of a live request.
Follow the RFC reference or current IANA registry entry when exact behavior, registration, or updated wording matters.
Use cases
See how the tool fits into real work and everyday tasks.
Look up a response number in a copied server log, then use the request context and logs to investigate the cause.
Check whether a documented example places a code in the informational, success, redirection, client-error, or server-error class.
Browse the selected entries to learn common status-code names, then use the protocol specification for full semantics.
Q&A
Find concise answers to common questions and confusing cases.
No. It searches a static status-code table and does not request a URL or inspect a server response.
No. It contains a selected set of entries. Check the IANA registry for the maintained list of registered codes and follow its references for details.
No. RFC 9110 says 404 indicates that the origin server did not find a current representation or is unwilling to disclose that one exists; the code alone does not establish permanence.
The table is a concise static summary and may retain older labels or explanations. Use the current RFC and IANA registration reference when exact wording or status matters.
Notes
Review scope, result limitations, and important precautions before use.
This page is a selected static reference, not a live HTTP test, exhaustive registry, or incident diagnosis.
Related
Discover related tools, collections, and available API capabilities.