HTTP Status Code Lookup

A field guide to HTTP outcomes

An HTTP status code is a three-digit summary of how a server handled a request. It belongs to the response metadata, alongside headers and an optional body. The code does not tell the entire story, but it gives clients a stable first decision: continue, accept a result, follow redirection, correct a request, authenticate, wait, or report a server-side failure.

This HTTP status code lookup is an offline reference. Search by number, reason phrase, or words from a description; filter by 1xx through 5xx; select a row for technical details and an example; or copy the selected code and name. The catalog is bundled in the React component. Searching and filtering cause no fetch call and send no query to a server. The MDN link is the only network navigation initiated from the results, and it opens after you choose it.

Use the lookup while debugging

Enter 404, Not Found, or a term such as rate in the search box. Search matches the code, name, and short description, ignoring letter case. Category tabs narrow the same local list. If both a search and category are active, a result must satisfy both; a search for 500 under 4xx therefore returns no matches.

Select a card to populate the detail pane. The default is 200 OK. The page includes a curated set of common statuses rather than every IANA-registered or extension code, so absence from the list does not make a code invalid. The external MDN link is useful for deeper browser-focused documentation, while protocol requirements should be checked against current HTTP specifications.

The five classes as decisions

1xx Informational responses are interim. 100 Continue allows a client to proceed with a request body after sending Expect: 100-continue. 101 Switching Protocols acknowledges a protocol upgrade such as WebSocket over HTTP/1.1. 103 Early Hints can advertise preload links before a final response. A client still expects a final non-1xx response.

2xx Success means the server accepted and handled the request in the way represented by the specific code. It does not guarantee the business result a user expected. A 202 Accepted confirms queuing, not completion; 204 No Content forbids a response body; 206 Partial Content answers a range request.

3xx Redirection either redirects the client or describes cache validation. 301 and 308 are permanent, while 302 and 307 are temporary. 307 and 308 explicitly preserve the HTTP method and body. 304 Not Modified is not a navigation redirect and normally accompanies conditional requests; the client reuses its stored representation.

4xx Client Error indicates the request cannot be fulfilled as sent or under the current client context. “Client” can include an SDK, reverse proxy, browser state, or caller identity rather than an end user. Many 4xx errors should not be retried unchanged.

5xx Server Error indicates that a server or intermediary failed while handling an apparently valid request. Retries can help for transient cases, but uncontrolled retries can amplify overload. Use bounded exponential backoff, jitter, idempotency awareness, and Retry-After where applicable.

Status pairs engineers commonly confuse

200 versus 201 versus 204

Return 200 OK for a successful response with a representation. Use 201 Created when a request creates a resource; include a Location header when practical. Use 204 No Content when success needs no body. A 204 response must not contain a message body, so clients should not attempt JSON parsing merely because an endpoint usually returns JSON.

202 versus completed work

202 Accepted means processing has not necessarily finished. An asynchronous API should provide a job resource, status URL, callback mechanism, or other way to determine completion and failure. Returning 202 and then losing the job is not successful processing.

301/302 versus 307/308

Historical client behavior can change POST to GET after 301 or 302. Use 307 or 308 when method and body preservation is required. Before making a redirect permanent, verify destination, caching behavior, and rollback strategy because clients and intermediaries may retain it.

400 versus 422

400 Bad Request suits malformed syntax, invalid framing, or a request that cannot be parsed. 422 Unprocessable Content is useful when syntax and media type are understood but instructions fail semantic validation. APIs should apply one documented convention consistently rather than debating labels while returning an unhelpful body.

401 versus 403

401 Unauthorized conventionally means authentication is missing or invalid and normally includes WWW-Authenticate. Despite its name, it is about authentication. 403 Forbidden means the server understood the request but refuses it, often because an authenticated principal lacks permission. Some systems deliberately use 404 to conceal the existence of protected resources.

404 versus 410

404 Not Found says no current representation was found or the server will not disclose one. 410 Gone makes permanence explicit and can help clients retire references. Neither code should reveal sensitive resource existence contrary to the application’s authorization design.

409 versus 412

The bundled list includes 409 but not 412. 409 Conflict represents a conflict with current resource state, such as a naming collision. 412 Precondition Failed is appropriate when headers such as If-Match fail, often preventing lost updates. The catalog’s omissions are one reason to consult the standards for API design.

502 versus 503 versus 504

502 Bad Gateway means a gateway received an invalid upstream response. 503 Service Unavailable means a service is temporarily unable to handle work, perhaps due to maintenance or overload. 504 Gateway Timeout means an intermediary did not receive an upstream response in time. Investigate the component that generated the code, not merely the browser-facing hostname.

Worked incident: an upload fails with 413

A browser upload receives 413 Content Too Large. Check the response body and Server or proxy headers to identify the layer. A CDN, ingress controller, Nginx proxy, framework parser, and application can each enforce a different maximum. Raising only the application setting will not help if the edge rejects the body first.

Confirm units, route-specific policy, compressed versus decoded size, and whether the connection closes before a body is returned. If the server provides Retry-After, the condition may be temporary, though size limits are usually deterministic. Improve the client by validating size before transfer and presenting the actual accepted limit. Do not automatically retry the same oversized body.

Worked incident: intermittent 504 responses

A 504 Gateway Timeout during report generation points to an intermediary waiting too long for upstream. Correlate gateway request IDs with application traces. Compare gateway timeout, server timeout, database duration, and client cancellation. Simply increasing every timeout can tie up resources and move failure elsewhere.

A better design may submit the report, return 202 Accepted, and expose job status. If the operation is safely retryable, clients can use backoff. For non-idempotent requests, use idempotency keys or status reconciliation to avoid duplicate work after an ambiguous timeout.

Codes, methods, and bodies belong together

The same code can mean different things by method. 200 after GET carries a selected representation; after POST it may describe an action result. 201 is most natural after creation. 204 after DELETE indicates completion without content. 405 Method Not Allowed requires an Allow header listing supported methods for the target resource.

Response bodies should use a documented media type and machine-readable error shape where useful. Do not send HTTP 200 with { "success": false } for every application failure; doing so breaks generic clients, monitoring, and retry logic.

Headers refine behavior. Location accompanies creation or redirection, Retry-After can guide retries, WWW-Authenticate defines a challenge, Allow accompanies 405, and validators such as ETag work with conditional requests. The status code lookup explains individual codes but does not simulate these interactions.

Client behavior and safe retries

GET, HEAD, PUT, and DELETE are defined as idempotent at the semantic level, though broken implementations and side effects exist. POST is not generally idempotent. Retry only after considering method, payload, whether the server may have completed work, and whether an idempotency mechanism exists.

For 429 and transient 5xx responses, respect Retry-After, cap attempts, apply exponential backoff with jitter, and stop on permanent errors. Avoid synchronized retry storms. Browsers may automatically follow redirects; Fetch APIs expose redirect behavior controls, while command-line clients vary. Always know whether your diagnostic client followed a response before you report its final code.

Local behavior and limitations

All catalog filtering occurs via useMemo over the bundled array. The tool does not query an endpoint, inspect a URL, test server availability, or show live status. Copy uses navigator.clipboard, which can fail outside a secure context or under restrictive permissions. Opening an MDN reference sends a normal browser request to developer.mozilla.org in a new tab with noopener noreferrer protections.

Reason phrases are explanatory labels and are not required in HTTP/2 or HTTP/3 framing. Applications should branch on numeric codes and documented semantics, not exact phrase text.

Questions from API reviews

Should validation errors use 400 or 422?

Either can form a coherent API convention. Distinguish parsing from semantic validation if that helps clients, document the choice, and return actionable field errors without leaking sensitive internals.

Does 200 mean the returned data is correct?

No. It means the request succeeded according to the server. Business correctness, freshness, and schema validity require separate checks.

Can a response have multiple status codes?

A transaction can receive informational 1xx responses before one final status. Redirect chains and authentication retries also contain multiple HTTP responses, each with its own final code for that hop.

Why is my browser showing 200 after I expected 304?

DevTools settings, cache disabling, service workers, revalidation behavior, or an intermediary may change the transaction. A browser can also present a cached resource in ways that obscure the network exchange. Inspect the detailed timing and transferred-size indicators.

Is every 5xx safe to retry?

No. The operation may have completed before the failure reached the client, and overload may worsen. Consider idempotency and server guidance.

Why is a status missing from this lookup?

The component intentionally contains a limited reference set. Check the IANA HTTP Status Code Registry and the relevant specification for authoritative registration and semantics.