HTTP Status Code Reference & Security Implications

Look up any HTTP status code with security and caching implications explained

Ad placeholder (leaderboard)

HTTP status codes are the three-digit numbers a server returns to tell a client what happened to its request. Choosing the right one matters for correctness, caching and security — a misused 403 can leak the existence of hidden resources, and a 200 returned for an error breaks client retry logic. This reference explains each registered code with its correct use, common misuse, security implications and default caching behaviour, all bundled offline.

How it works

Status codes are grouped into five classes by their first digit:

  • 1xx Informational — request received, continuing.
  • 2xx Success — the request succeeded.
  • 3xx Redirection — further action (usually a new URL) is needed.
  • 4xx Client error — the request is malformed or unauthorised.
  • 5xx Server error — the server failed to fulfil a valid request.

Type a number, a class like 4xx, or a keyword. The tool filters a bundled dataset and shows the reason phrase plus the notes that matter most when building or securing an API.

Security notes

Two codes deserve special care. Use 401 Unauthorized when no valid credentials were supplied and the client may retry after authenticating. Use 403 Forbidden when credentials are valid but authorisation is denied. For sensitive resources, returning 404 instead of 403 avoids confirming that a hidden path exists — a common information-disclosure hardening step.

Caching notes

Per RFC 9111, several status codes (200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, 451, 501) are heuristically cacheable even without explicit Cache-Control. If an error response should never be stored, send Cache-Control: no-store.

Ad placeholder (rectangle)