Every HTTP status code explained — descriptions, use cases, headers, SEO impact, and dev tips. Searchable & filterable.
This reference covers all 60+ standardized HTTP status codes across the five classes. Each entry includes a plain-English description, a practical use case, relevant HTTP request and response headers, a developer tip, and the defining RFC. Use the live search to find any code by number, name, or keyword (e.g. "redirect", "cache", "auth").
The reference is fully interactive — no page reload needed:
HTTP responses are grouped by their first digit. 1xx codes are informational continuations. 2xx signals success. 3xx indicates redirection — further action is required. 4xx means the client made an error. 5xx means the server failed. Knowing the class instantly tells you where to look when debugging: 4xx = fix the request, 5xx = fix the server.
301 passes full link equity (PageRank) to the new URL and updates Google's index permanently — use for all permanent moves. 302 is temporary and does not transfer equity long-term. Returning 200 for pages with no content (soft-404s) confuses crawlers. Use 410 instead of 404 for intentionally removed content — Google de-indexes 410 pages significantly faster than 404s.
Use
201
when a resource is created, not 200. Return
204
for successful DELETE or PUT with no body. Use
422
for validation errors (semantically invalid input),
401
for missing authentication, and
403
when auth succeeds but permission is denied. Use
429
for rate limiting with a
Retry-After
header. Never return
200
with an error payload — it breaks client error handling.
WWW-Authenticate
header. Re-authenticating may help.
403 (Forbidden)
means authentication succeeded but the server refuses to authorize the request — you don't have the required permission. Re-authenticating will not help. Mnemonic: 401 = "Who are you?", 403 = "I know who you are, but no."
Location
header pointing to the new resource (e.g.,
Location: /users/42
) so clients can reference it immediately. Use
204 (No Content)
for successful DELETE or PUT operations when there is nothing to return. Return
202 (Accepted)
for async operations where the resource is queued but not yet created. Never use 200 for creation — the semantic distinction matters for API clients and monitoring tools.