HTTP Status Codes Cheat Sheet

The class tells a client how broadly to interpret the response. A client should generally handle unknown codes according to their class and preserve response headers and body when useful.

Informational responses are usually handled by protocol-aware clients. Success codes distinguish returned content, resource creation, and an intentionally empty response.

HTTP/1.1 201 Created
Location: /users/42
Content-Type: application/json

{"id":42,"name":"Ada"}

Redirect codes tell a client to use another target or indicate that a cached representation remains valid. 301 and 308 are permanent; 302 and 307 are temporary. The 307 and 308 forms preserve the request method and body during the redirect.

A 4xx response means the server considers something about the request invalid, unauthorized, forbidden, missing, conflicting, or rate-limited. APIs should return a useful body when clients can correct the request.

401 concerns authentication; 403 concerns authorization. A 401 response commonly includes a WWW-Authenticate challenge, while 403 does not require the client to authenticate differently.

5xx responses indicate a failure while processing a request the server could not complete. Gateways and proxies may generate some of these codes on behalf of an upstream service.

HTTP/1.1 503 Service Unavailable
Retry-After: 120
Content-Type: application/json

{"error":"temporarily unavailable"}

Treat status classes separately and respect headers such as Location, Retry-After, and caching validators. Retrying a request is safe only when the operation and server contract make it safe; use backoff for transient failures.

if (response.status === 429 || response.status >= 500) {
  const retryAfter = response.headers.get("Retry-After");
  // Apply bounded backoff according to the API contract.
} else if (!response.ok) {
  throw new Error(`Request failed: ${response.status}`);
}

• MDN HTTP response status codes
• RFC 9110: HTTP Semantics