HTTP status code/API error code detailed catalog | ZeroTools

In communications between Web systems, HTTP status codes play an important role in expressing the processing result of a request as a three-digit number.

The representative 23 codes included in this tool are also classified into five classes based on protocol definitions.

The 100s (1xx) are called informational responses, indicating that processing is ongoing. For example, 100 Continue tells the client that it may continue sending the request body.

The 200s (2xx) are success responses, meaning that the client's request was successfully received, understood, and processed on the server side.

Besides the common 200 OK, this includes 201 Created indicating resource creation completion.

The 300s (3xx) are a class that directs redirection (transfer). They are used when the requested resource has moved to a different URL or to encourage the use of a cache.

The 400s (4xx) indicate client errors, notifying that there is a problem with the requester, such as an incorrect request syntax or insufficient authentication or authorization.

Finally, the 500s (5xx) represent server errors, indicating a state where the client's request may have been appropriate, but the server could not complete the processing due to reasons like exceptions or overload on the server side (though 5xx does not guarantee the client request was actually correct).

Accurately understanding these five classes is the foundation of error handling in API integration and frontend development. By utilizing this tool's error quick reference, it is possible to quickly isolate whether the problem that occurred originated on the client side or the server side, although the status code alone cannot definitively determine the root cause of the failure.

To support rapid troubleshooting investigations in development environments, this tool functions as an HTTP status code detailed explanation reference equipped with intuitive search and classification features.

The "Catalog Search" area at the top of the screen features a search box and six tabs (ALL, 1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Error, 5xx Server Error).

By entering a code number (e.g., 404) or name (e.g., Not Found), or keywords included in the translated name or description into the search box, the corresponding status codes are immediately filtered and displayed in the list on the left.

Note that Japanese names are translated to English, so Japanese search functionality is not guaranteed. By switching tabs, you can filter only specific classes, allowing you to quickly reach the desired information as an error quick reference when encountering unknown codes.

The 200 code is selected by default.

Clicking any item in the list on the left displays the code's definition, translated name, and related RFC section information in the detail panel on the right.

As a learning API response catalog of 23 fixed codes, this tool is designed so you can also check illustrative examples of HTTP response headers and bodies (JSON or HTML).

There is no actual HTTP communication, URL testing, or mock server startup.

The information provided here is strictly an excerpt limited to 23 representative codes. Because it does not comprehensively cover all status codes, it does not completely replace the official registry managed by IANA (Internet Assigned Numbers Authority).

However, it performs well enough for quickly checking the meanings of frequently occurring status codes in daily development and judging the validity of code selection.

Status codes in the 300s primarily instruct the client on additional actions accompanying the movement of resources or changes in state.

This tool includes 301 Moved Permanently, 302 Found, and 304 Not Modified as representative examples.

301 Moved Permanently indicates that the requested resource has permanently moved to a new URL. The server often responds with the new transfer destination in the Location header.

Clients like browsers generally cache this destination and automatically redirect access to the new URL on subsequent visits. On the other hand, 302 Found indicates a temporary move.

However, whether 301 or 302 is actually cached depends on explicit instructions like Cache-Control or Expires, heuristics, and client implementations, not just the status code alone.

304 Not Modified is a code that tells the client the resource has not been updated in response to a conditional request (using If-None-Match or If-Modified-Since).

This response does not contain a body, and the client reuses the local cached data it holds. This saves unnecessary data transfer, conserving network bandwidth and speeding up display.

When reviewing the detailed explanations of the 300s, you must also consider interactions with these headers and settings.

Status codes in the 400s indicate that there was some flaw in the request sent by the client, and the server refused to process it.

In frontend development and API client implementation, appropriately investigating and fixing the causes of receiving these codes is extremely important.

400 Bad Request is a code broadly referring to request syntax errors, such as invalid JSON formatting or missing parameters. 401 Unauthorized indicates missing or failed authentication, meaning valid tokens or similar are needed to access the target resource.

403 Forbidden means that the client lacks viewing or operation permissions for the target resource. However, it does not guarantee that authentication was successful; the exact reason cannot be definitively determined, as it could be due to WAF blocking or IP restrictions.

The most widely recognized code on the Web, 404 Not Found, indicates that the requested resource does not exist, but it is sometimes returned instead of a 403 to hide the resource's existence for security reasons.

Additionally, 429 Too Many Requests represents exceeding a rate limit. When receiving a 429, some servers may append a Retry-After header indicating the grace period in seconds or a specific HTTP date before retrying.

However, this header is optional and not guaranteed to be present, so you must implement appropriate backoff processing based on the API specifications and actual response headers.

Status codes in the 500s indicate a state where an unexpected exception occurred on the server side, or normal processing could not be completed due to overload.

Since the client's request itself is often correct (though not guaranteed), investigations are needed using the error quick reference to isolate which tier of the infrastructure or backend application has the problem.

500 Internal Server Error is a generic code comprehensively indicating any failure occurring inside the server, such as program bugs, database connection failures, or configuration file description errors.

To pinpoint the cause, you must check server-side application logs or error monitoring tools. A status code alone cannot definitively diagnose the issue.

Meanwhile, in architectures routing through load balancers, reverse proxies, or API gateways, 502 Bad Gateway and 504 Gateway Timeout can occur.

502 means the proxy server received an invalid response from the upstream server, often suggesting process crashes or network disconnections.

504 indicates that a response from the upstream server was not obtained within the time limit; possible examples include database locks or heavy processing timeouts.

Always investigate upstream logs and network states.

503 Service Unavailable indicates that the server is currently in a temporary overloaded state or undergoing maintenance. This state is often temporary, and a Retry-After header might be attached just like with 429, but you cannot definitively conclude that a retry will always be possible.

You must consider an appropriate handling policy based on the system's load situation and operational policy.

When a status code is selected in this tool, sample HTTP response headers and bodies are displayed in the detail explanation panel as illustrative examples.

These mock examples are curated for educational reference across 23 representative status codes, rather than serving as live API measurements or complete wire-level protocol serializations.

For instance, the 304 Not Modified example provides three distinct line-feed-separated header lines featuring ETag: W/"5d3b-abcdef" alongside Cache-Control: max-age=3600, while the default 200 OK mock provides a fixed Content-Length: 41 that matches its specific 41-byte UTF-8 sample body.

Note that Content-Length cannot generally be assumed to match body length across all HTTP responses, particularly in special cases like HEAD or 304 responses where payloads are omitted or handled differently.

Always review the official RFC definitions and target API documentation rather than assuming these mock snippets represent complete network frames.

For example, you can explore realistic response samples where JSON data is returned upon a 200-level success, structured error descriptions appear for 400-level client errors, and HTML error pages accompany 500-level infrastructure failures.

When copying header or body snippets, the panel's copy action asynchronously awaits the clipboard API promise, providing visible feedback upon success and displaying an explicit failure message if clipboard permissions or operations fail.

Furthermore, selecting a different status code, modifying the search query, or switching category filter tabs immediately invalidates and resets any active copy feedback indicators, and status codes lacking a response body omit the body copy button entirely.

These mock examples offer a practical starting baseline when assembling local mock servers or documentation drafts, provided you corroborate actual payload requirements with your production environment.

However, the content shown here is merely an example. The actual combinations of headers returned by Web applications and API servers, the JSON structure of error responses, and cache control directives vary widely depending on the individual settings of the framework or server used.

Avoid decisively adopting these examples as specifications for your production environment, and always check the actual behavior of the target system being developed.

Furthermore, this tool is an error quick reference that excerpts 23 representative codes and does not comprehensively cover all status codes defined in the HTTP protocol.

418, for instance, is currently classified as Unused by IANA (RFC 9110) and remains a historical joke. If you encounter unrecorded codes or wish to deeply understand strict definitions, we recommend referring to the official IANA HTTP Status Code Registry.