HTTP status codes

What it means

An HTTP status code is a three-digit field in a server's HTTP response. Its first digit describes the broad class: 1xx informational, 2xx success, 3xx redirection, 4xx client-side error conditions and 5xx server-side error conditions. A code is not the same as a transport error. If TCP or TLS fails before the server delivers an HTTP response, the client has no HTTP status to report. Even 200 OK does not guarantee that application data represents a successful business operation.

Try it

Simulation — interpret a response in context. Start at 200 but select an application-validation failure, then select 204, 304, or a vendor-specific 499. Choose a failed connection to see why a transport problem cannot be labeled 500. Change request method to HEAD and inspect whether a response body is appropriate. The result includes class, status name where standardized, body allowance and unknowns. Reset removes the altered case.

How the mechanism works

A browser or client first establishes a connection, then exchanges HTTP request and response messages. Status codes are interpreted together with request method, headers and representation. 204 No Content forbids response content; 304 Not Modified is a response to conditional retrieval indicating an existing stored representation can be reused under cache rules, not a typical Location redirect. HEAD has GET-like response metadata but no response content. 404 Not Found says a representation for the target resource was not found or disclosed; 502 and 504 concern gateway/upstream handling.

Implementations can use extension or vendor-specific codes. The numerical 4xx class can be recognized even if a particular 499 label is not assigned a universal standardized meaning. A JSON body may report a domain-specific validation failure while the HTTP transport succeeded with 200. Conversely, a failed TCP handshake cannot be turned into an HTTP status by guessing the intended server-side cause.

Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.

In practice

When diagnosing, record the actual HTTP status line and sanitized request method/target only if a response was received. Distinguish a proxy's status from an upstream's and compare relevant server logs with request IDs. For rate limits or temporary errors, consult documented retry rules and method idempotency rather than automatically resending writes. In high-risk environments, use read-only observations first; do not change routing or restart infrastructure from a code alone.

Limits and common mistakes

The scene includes representative standardized codes, not the full live IANA HTTP Status Code Registry. Payload handling depends on method and context. An HTTP code alone cannot determine server health, DNS correctness, TLS trust, or whether a financial or database operation committed.

Key takeaways

Read HTTP status alongside the request method, headers and application result. A 204 has no response content, a 304 supports cache validation, and a transport failure has no HTTP status at all. Unregistered vendor codes may be seen, but they do not acquire an IETF-wide meaning from their first digit.