HTTP status lookup

Developer tools

Loading tool

Preparing the tool. The remaining time is not yet known.

All processing for this tool happens in your browser. Your input is not sent to a server.

About this tool

Have a status number from a failed request? Enter one code to see its category, English phrase and explanation, then use the checks below to decide what evidence to inspect next. For keyword search and category browsing across the full curated reference, open the HTTP status code table in related tools.

Common uses

Interpret one code from browser developer tools, an API client or a server log.
Choose the next request, response-header or log check without assuming the code proves a root cause.
Copy a concise code definition into a bug report alongside the actual request details.

How to use it

1.Enter an integer from 100 to 599, such as 404 or 503; results update automatically.
2.Read the code, phrase, category and meaning. An unlisted code shows only its class and an unknown-code notice.
3.Use the guidance below with response headers/body and server logs. Copy the definition or clear the input for another lookup.

Examples

Missing resource lookup

404 Not Found

The phrase identifies the status, not the cause. Compare the URL path and routing with the expected endpoint.

Rate-limit lookup

429 Too Many Requests

Inspect rate limits and Retry-After when present. This lookup does not calculate a retry delay.

Gateway-timeout lookup

504 Gateway Timeout

Inspect gateway/upstream timing and logs. This lookup does not test the upstream service.

Common errors and checks

Do not enter a URL, an entire HTTP response line, a fraction or a number outside 100–599.
Do not interpret every 4xx as an incorrect password or every 5xx as proof that the origin server is down.
Do not blindly retry a state-changing request. Check method semantics and the service’s idempotency and retry rules.

Limits and notes

This is a local numeric lookup; it does not request a URL, test an endpoint, inspect live headers or automatically diagnose a failure.
The built-in common-code list is not the complete IANA registry. Unknown numbers are classified by their first digit, not assigned an invented meaning.
A status code cannot identify the responsible service or root cause on its own; proxies and application-specific responses need context.

Frequently asked questions

What should I check for 401 or 403?

For 401, inspect the authentication challenge and the credentials actually sent. For 403, inspect permissions and service policy. A JWT decoder can reveal claims but cannot prove that the credentials are valid.

What should I check for 404?

Compare the requested path, method and environment with the documented endpoint, then inspect routing and resource existence. A server may also use 404 to hide a forbidden resource; the code alone cannot distinguish that case.

What should I check for 429 or 503?

Check Retry-After if supplied and the service’s retry policy before retrying. For 429, review request rate and quota; for 503, review availability and maintenance signals. Avoid blind retries, especially for operations with side effects.

How do I investigate 502 versus 504?

Both involve a gateway or proxy: 502 reports an invalid upstream response, while 504 reports a timely upstream response was missing. Correlate gateway and upstream logs, timing and request IDs to investigate.