HTTP Status Codes

The five categories: 1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error.

The most-used codes appear daily; the rest are worth recognizing.

Daily Encounter

The seventeen status codes operators see most. 200 / 201 / 204 for success; 301 / 302 / 304 for redirects and caching; 400 / 401 / 403 / 404 / 409 / 422 / 429 for client-side problems; 500 / 502 / 503 / 504 for server-side. Most production logs are 90% these.

Code	Meaning
200 OK	standard success
201 Created	resource created (often with Location:)
204 No Content	success with no response body
301 Moved Permanently	redirect (cacheable)
302 Found	temporary redirect
304 Not Modified	conditional GET; client can use its cache
400 Bad Request	malformed / invalid input
401 Unauthorized	missing or invalid authentication
403 Forbidden	authenticated but not allowed
404 Not Found	resource doesn’t exist
409 Conflict	conflicts with current state (race / version mismatch)
422 Unprocessable Entity	validation failed
429 Too Many Requests	rate-limited; check Retry-After
500 Internal Server Error	unexpected server failure
502 Bad Gateway	upstream returned an invalid response
503 Service Unavailable	temporarily unable to handle (overloaded / maintenance)
504 Gateway Timeout	upstream didn’t respond in time

1xx Informational

Provisional responses sent before the final one. 100 Continue greenlights a body upload after the headers; 101 is the WebSocket / HTTP/2 upgrade handshake; 103 carries early preload hints for browsers. Rarely seen in user-side debugging logs.

Code	Meaning
100 Continue	server received headers; client should send body
101 Switching Protocols	WebSocket / HTTP/2 upgrade
102 Processing	server is working (WebDAV)
103 Early Hints	preload hints before final response

2xx Success

The success class. 200 is the default; 201 with Location: is the REST convention for “created”; 202 is the async / queued acknowledgement; 204 means “done, no body needed”; 206 is the byte-range response that powers resumable downloads.

Code	Meaning
200 OK	-
201 Created	resource created
202 Accepted	queued for async processing
203 Non-Authoritative Information 204 No Content	proxy modified the response
205 Reset Content	client should reset its view (form)
206 Partial Content	byte-range response
207 Multi-Status	multiple sub-results (WebDAV)
208 Already Reported	WebDAV
226 IM Used	delta encoding

3xx Redirection

The redirect family. 301 / 308 are permanent; 302 / 307 are temporary; the historical 301 / 302 don’t preserve the request method while the modern 307 / 308 do, which is the distinction that matters when redirecting a POST.

Code	Meaning
300 Multiple Choices	several options available
301 Moved Permanently	permanent redirect; future requests should use the new URL
302 Found	temporary redirect; method may change to GET
303 See Other	redirect to a GET (used after POST)
304 Not Modified	cache hit on conditional GET
305 Use Proxy	deprecated
307 Temporary Redirect	same method preserved
308 Permanent Redirect	same method preserved

The 301 / 302 / 307 / 308 distinction:

Code	Permanent / Temp	Method preserved?
301	Permanent	historically not (now SHOULD be)
302	Temporary	historically not (now SHOULD be)
307	Temporary	yes (RFC-strict)
308	Permanent	yes (RFC-strict)

Use 307 / 308 when method preservation matters.

4xx Client Errors

The client-side failure modes. 401 vs 403 trips up newcomers (401 = “we don’t know who you are”; 403 = “we know, you’re not allowed”); 422 is the validation-failure code most JSON APIs adopted; 429 is the rate-limit response with Retry-After.

Code	Meaning
400 Bad Request	-
401 Unauthorized	missing / invalid auth (response usually has WWW-Authenticate)
402 Payment Required	reserved; some APIs use it for billing
403 Forbidden 404 Not Found	authenticated but disallowed (no WWW-Authenticate)
405 Method Not Allowed	must include Allow header
406 Not Acceptable 407 Proxy Authentication Required	Accept header mismatch
408 Request Timeout 409 Conflict	client too slow
410 Gone 411 Length Required	resource intentionally removed (vs. 404 unknown)
412 Precondition Failed 413 Content Too Large 414 URI Too Long 415 Unsupported Media Type 416 Range Not Satisfiable 417 Expectation Failed	If-Match / If-Unmodified-Since failed
418 I’m a teapot	RFC 2324 (April Fools’); used in practice for “no, really not”)
421 Misdirected Request	HTTP/2 with wrong authority
422 Unprocessable Content	validation failed (WebDAV; widely reused)
423 Locked	WebDAV
424 Failed Dependency	WebDAV
425 Too Early 426 Upgrade Required	request was a TLS replay
428 Precondition Required	client should use If-Match
429 Too Many Requests 431 Request Header Fields Too Large 451 Unavailable For Legal Reasons	rate-limited

5xx Server Errors

The server-side failure modes. 500 is the catch-all; 502 / 503 / 504 are the load-balancer / upstream-trouble codes; 503 with Retry-After is the polite way to ask a client to back off during maintenance.

Code	Meaning
500 Internal Server Error	catch-all server failure
501 Not Implemented	method not supported by server
502 Bad Gateway	invalid response from upstream
503 Service Unavailable	overloaded / maintenance; Retry-After advisable
504 Gateway Timeout 505 HTTP Version Not Supported 506 Variant Also Negotiates	upstream too slow
507 Insufficient Storage	WebDAV
508 Loop Detected 510 Not Extended	WebDAV
511 Network Authentication Required	captive portal

Idempotent Methods

The expectation, per RFC 9110:

Method	Safe	Idempotent
GET	yes	yes
HEAD	yes	yes
OPTIONS	yes	yes
TRACE	yes	yes
PUT	no	yes
DELETE	no	yes
POST	no	no
PATCH	no	no (commonly)

Retry only idempotent calls. POST retries need an idempotency key.

Cache-Control Cheat Sheet

The Cache-Control directives that come up most. no-store for sensitive data; immutable + a long max-age for hashed build assets; stale-while-revalidate for the “serve cached while we refetch in the background” pattern.

Directive	Effect
no-store	never cache
no-cache private browsers only; not shared caches public shared caches OK	may cache, must revalidate
max-age=N s-maxage=N shared-cache freshness override	fresh for N seconds
must-revalidate	fail if origin unreachable
immutable	never re-validate (long-lived hashed assets)
stale-while-revalidate=N	serve stale while fetching

Useful Headers Around Status

The headers that pair with status codes to communicate retry behavior, conditional requests, and content negotiation. Each one is a small piece of HTTP semantics that reads like trivia until you debug a misbehaving CDN.

Header	Use
Location	target of 201 / 3xx
Retry-After	seconds or HTTP-date for 429 / 503
WWW-Authenticate	401 challenge
Allow	405 supported methods
ETag	cache validator
Last-Modified	cache validator
If-Match / If-None-Match	conditional requests
Vary	which request headers vary the response

HTTP/2 / HTTP/3 Notes

The status codes are unchanged across HTTP versions. The differences are framing, connection management, and prioritization. A 200 in HTTP/2 means the same thing as a 200 in HTTP/1.1.