HTTP Status Code Reference

Every HTTP status code with description, RFC source, and typical use. Searchable by code, name, or use-case.

published

  • [FREE]
  • [NO_SIGNUP]
  • [NO_UPLOAD]

A complete HTTP status code reference: every code defined across RFC 9110, RFC 9112, RFC 4918 (WebDAV), and the RFC 6585 + 7538 extensions. Each entry includes the description, the RFC source, and the typical real-world use.

Categories at a glance

  • 1xx Informational — the request was received; continue processing
  • 2xx Success — the request was successfully received, understood, and accepted
  • 3xx Redirection — further action needs to be taken to complete the request
  • 4xx Client Error — the request contains bad syntax or cannot be fulfilled
  • 5xx Server Error — the server failed to fulfill an apparently valid request

Privacy

Static reference data bundled with the page. No tracking, no analytics on which codes you look up.

Frequently asked questions

What does HTTP status 200 mean?

200 OK is the default success response for any HTTP request — GET, PUT, POST, DELETE. The server processed the request and the response body contains whatever was requested (or an empty body for methods that produce no content).

What is the difference between 401 and 403?

401 Unauthorized means authentication failed or is missing — the client should retry with credentials (and the server SHOULD send a `WWW-Authenticate` header). 403 Forbidden means authentication succeeded but the client lacks permission for the resource — no retry will help.

301 vs 308?

Both are permanent redirects. 301 (older) allows the client to change the HTTP method on the follow-up (historically, browsers turned POSTs into GETs). 308 (newer) forbids method change — useful for permanently moved POST endpoints.

Should I return 422 or 400 for validation errors?

400 is for malformed framing (bad JSON, missing headers). 422 is the semantic-validation status — well-formed but invalid data. Modern API style guides (JSON:API, OpenAPI Spec community) prefer 422 for "your fields are wrong."

What is 429 and how should clients respond?

429 Too Many Requests means the server is rate-limiting you. The response SHOULD include a `Retry-After` header — either a number of seconds or an HTTP-date. Clients should back off rather than retry tightly.