PK Systems PK Systems
Web & marketing

HTTP Status Code Reference

Search and learn the meaning, typical cause and use case of every common HTTP status code, with cURL/Python/JS/PHP snippets.

HTTP Status Code Reference

100 Continue #

An interim response that signals the server has received the request headers and the client should proceed to send the request body. Defined in RFC 9110 section 15.2.1.

Common cause

The client sent an Expect: 100-continue header to test whether the server will accept a large body before transmitting it.

When to use it

Used between the headers and the body of long uploads (PUT, POST) so the client doesn’t waste bandwidth on a request the server would reject.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 100 Continue
101 Switching Protocols #

The server agrees to switch to a different application protocol on the same TCP connection, listed in the Upgrade header. RFC 9110 §15.2.2.

Common cause

The client requested an Upgrade (typically to WebSocket or HTTP/2 over h2c) and the server accepted it.

When to use it

WebSocket handshakes are the dominant case today. After 101 the connection is no longer HTTP.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 101 Switching Protocols
200 OK #

Standard success response — the request succeeded and the response body carries the requested representation. RFC 9110 §15.3.1.

Common cause

The request was valid, authorised and satisfied without redirection.

When to use it

GETs that return data, POSTs/PUTs that processed inline rather than asynchronously, healthy API responses.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 200 OK
201 Created #

The request succeeded and a new resource was created as a direct result. The Location header SHOULD point to the new resource. RFC 9110 §15.3.2.

Common cause

A POST or PUT created a resource (a database row, a file, a user, etc.).

When to use it

Use after creating REST resources. Return the new representation in the body and a Location header.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 201 Created
202 Accepted #

The request has been accepted for processing but is not yet complete. The processing may eventually succeed or fail. RFC 9110 §15.3.3.

Common cause

Asynchronous processing has been queued. The work happens later.

When to use it

Background jobs, batch import endpoints, anything that returns a job-status URL while the work is still running.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 202 Accepted
204 No Content #

The request succeeded; the response intentionally has no body. Headers may carry metadata. RFC 9110 §15.3.5.

Common cause

An update or delete that doesn’t need to return a representation.

When to use it

DELETE responses, PUT/PATCH where the client already has the new representation, save-and-stay endpoints.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 204 No Content
206 Partial Content #

The server returned only part of the representation in response to a Range request. RFC 9110 §15.3.7.

Common cause

The client asked for a byte range using the Range header.

When to use it

Resumable downloads, video streaming with seek, and parallel chunk downloads.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 206 Partial Content
301 Moved Permanently #

The target resource has a new permanent URI. Clients SHOULD update bookmarks and search engines update their indexes. RFC 9110 §15.4.2.

Common cause

A canonical URL change — domain rename, slug fix, HTTPS migration.

When to use it

Long-term redirects. Avoid 301 for short-lived redirects because clients and intermediaries cache aggressively.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 301 Moved Permanently
302 Found #

The target resource resides temporarily under a different URI. Clients should request the new URI without changing the method semantics, but historically most rewrite POST to GET. RFC 9110 §15.4.3.

Common cause

Temporary redirect with quirky method-rewrite behaviour, retained for legacy compatibility.

When to use it

Legacy code paths. Prefer 303 or 307 in new APIs to be unambiguous about method handling.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 302 Found
303 See Other #

Redirects to a resource that should be retrieved with GET, regardless of the original method. RFC 9110 §15.4.4.

Common cause

After a non-idempotent POST, the server sends the client to a confirmation page or a freshly-created resource.

When to use it

Post/Redirect/Get pattern. Always rewrites to GET, so safe after a form submission.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 303 See Other
304 Not Modified #

The cached representation the client already holds is still valid; no body is sent. RFC 9110 §15.4.5.

Common cause

The client sent If-None-Match or If-Modified-Since and the validators matched the current resource.

When to use it

Conditional GET responses for caching. Saves bandwidth on unchanged static assets and API replies.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 304 Not Modified
307 Temporary Redirect #

Like 302 but explicitly preserves the request method and body. RFC 9110 §15.4.8.

Common cause

A short-term redirect where the original POST/PUT must be replayed at the new URI.

When to use it

Maintenance redirects, A/B routing or geo redirects that must keep the original method.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 307 Temporary Redirect
308 Permanent Redirect #

Like 301 but explicitly preserves the request method and body. RFC 9110 §15.4.9.

Common cause

A canonical URI change for non-GET methods (HTTPS upgrade for POST APIs, route renames).

When to use it

REST API permanent redirects. Use instead of 301 when the original method must not be rewritten.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 308 Permanent Redirect
400 Bad Request #

The server cannot process the request due to a client error: malformed syntax, invalid framing, deceptive routing. RFC 9110 §15.5.1.

Common cause

Broken JSON, missing required field, malformed header, oversized cookie.

When to use it

Generic client error fallback. Prefer more specific codes (422, 411, 415) when they apply.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 400 Bad Request
401 Unauthorized #

The request lacks valid authentication credentials. The response MUST include a WWW-Authenticate header listing accepted schemes. RFC 9110 §15.5.2.

Common cause

Missing, expired or invalid token; no Authorization header where one is required.

When to use it

API endpoints behind authentication. Distinct from 403 — 401 is "not authenticated", 403 is "authenticated but not allowed".

curl -i -X HEAD https://example.com/path
# HTTP/1.1 401 Unauthorized
403 Forbidden #

The server understood the request but refuses to authorise it. RFC 9110 §15.5.4.

Common cause

The user is authenticated but lacks permission, or the resource is blocked from the user’s IP / region.

When to use it

Authorization failures, IP allowlists, role-based access controls.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 403 Forbidden
404 Not Found #

The server can’t find a current representation of the target resource. May also be used to hide a 403. RFC 9110 §15.5.5.

Common cause

URL typo, deleted resource, or resource that never existed.

When to use it

Default response for missing routes and resources. Caches less aggressively than 410.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 404 Not Found
405 Method Not Allowed #

The method is not supported on the resource. The response MUST include an Allow header listing supported methods. RFC 9110 §15.5.6.

Common cause

Calling DELETE on a read-only collection, POST on a singleton resource, etc.

When to use it

REST APIs that want to be explicit about allowed verbs.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 405 Method Not Allowed
406 Not Acceptable #

The server cannot produce a representation matching the Accept-* headers. RFC 9110 §15.5.7.

Common cause

Client asked for application/xml but only application/json is available.

When to use it

Strict content negotiation. Many APIs default to JSON instead of returning 406.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 406 Not Acceptable
408 Request Timeout #

The server gave up waiting for the client to finish the request. RFC 9110 §15.5.9.

Common cause

Slow client connection, half-finished upload, idle keep-alive that exceeded the server timeout.

When to use it

Reverse proxies and load balancers fronting slow clients.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 408 Request Timeout
409 Conflict #

The request conflicts with the current state of the resource. RFC 9110 §15.5.10.

Common cause

Two clients edited the same record concurrently; unique-constraint violation; PUT with a stale ETag.

When to use it

Optimistic concurrency control, idempotent create endpoints.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 409 Conflict
410 Gone #

The resource was intentionally removed and will not return. RFC 9110 §15.5.11.

Common cause

Permanently deleted content; deprecated API endpoint that has been retired.

When to use it

Removed pages where you want crawlers to drop the URL faster than 404 would.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 410 Gone
411 Length Required #

The request lacks a Content-Length header where the server requires one. RFC 9110 §15.5.12.

Common cause

A streaming client that didn’t buffer the body or didn’t use chunked transfer encoding.

When to use it

Servers that disallow chunked uploads on certain endpoints.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 411 Length Required
413 Content Too Large #

The request body is larger than the server is willing to accept. RFC 9110 §15.5.14. Renamed from "Payload Too Large" in RFC 9110.

Common cause

Upload over the configured size limit, file beyond the maximum form size.

When to use it

File-upload endpoints, JSON APIs with body-size limits.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 413 Content Too Large
414 URI Too Long #

The request URI is longer than the server is willing to interpret. RFC 9110 §15.5.15.

Common cause

Massive query strings (often from forms submitted with method=GET) or URL-embedded tokens.

When to use it

When users hit your endpoint with abnormally long URLs — switch the form to POST.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 414 URI Too Long
415 Unsupported Media Type #

The server refuses to accept the body in the format described by the Content-Type header. RFC 9110 §15.5.16.

Common cause

Sending application/xml to a JSON-only endpoint, missing or wrong Content-Type.

When to use it

REST APIs that strictly accept only one or two media types.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 415 Unsupported Media Type
418 I’m a teapot #

An April-fools joke from RFC 2324 (HTCPCP). Some servers return it as a generic "refuse to brew" error. Not a real production status.

Common cause

Software that returns 418 deliberately, often to mark abuse traps or jokes.

When to use it

Easter eggs only. Don’t use in real APIs — many proxies and clients don’t recognise it.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 418 I’m a teapot
422 Unprocessable Content #

The syntax is fine but the server can’t process the semantic content. RFC 9110 §15.5.21. Originally introduced by WebDAV (RFC 4918).

Common cause

Validation errors on a structurally valid JSON payload — required field empty, value out of range.

When to use it

Form validation in modern APIs. Cleaner than 400 because the request is syntactically valid.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 422 Unprocessable Content
423 Locked #

The resource is locked. RFC 4918 (WebDAV).

Common cause

WebDAV resource that another user holds an exclusive lock on.

When to use it

Document collaboration servers, version-control front-ends.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 423 Locked
425 Too Early #

The server is unwilling to process a request that might be replayed, typically because it was sent in TLS 1.3 0-RTT (early data). RFC 8470.

Common cause

TLS 1.3 0-RTT request that the server treats as replay-unsafe.

When to use it

Protect non-idempotent endpoints from replay during 0-RTT handshakes.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 425 Too Early
428 Precondition Required #

The origin server requires the request to be conditional. RFC 6585.

Common cause

The server wants clients to use If-Match / If-Unmodified-Since to avoid lost-update conflicts.

When to use it

APIs with optimistic locking that refuse unconditional writes.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 428 Precondition Required
429 Too Many Requests #

The user has sent too many requests in a given time. RFC 6585.

Common cause

Rate limit hit; the response usually includes a Retry-After header.

When to use it

Rate-limited APIs, login throttling, abuse mitigation.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 429 Too Many Requests
431 Request Header Fields Too Large #

The server refuses to process the request because its header fields are too large. RFC 6585.

Common cause

An oversized cookie, an extremely long Referer or Authorization header.

When to use it

When session cookies grow beyond your reverse-proxy buffer; consider trimming or moving state to the body.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 431 Request Header Fields Too Large
451 Unavailable For Legal Reasons #

The resource is unavailable due to legal demands — a takedown order, geo-block, or DMCA. RFC 7725.

Common cause

Court order, regulator takedown, GDPR right-to-erasure response.

When to use it

Compliance teams that need to be transparent about why a page is blocked.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 451 Unavailable For Legal Reasons
500 Internal Server Error #

The server encountered an unexpected condition that prevented it from fulfilling the request. RFC 9110 §15.6.1.

Common cause

Unhandled exception, application bug, broken dependency, runaway query.

When to use it

Catch-all server error. Always log a stack trace and a request ID so users can quote it.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 500 Internal Server Error
501 Not Implemented #

The server does not support the functionality required to fulfil the request. RFC 9110 §15.6.2.

Common cause

Unknown method, feature flag disabled, code path stubbed.

When to use it

API endpoints that exist but are not yet built. Prefer 405 if the method is wrong but others work.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 501 Not Implemented
502 Bad Gateway #

The gateway or proxy got an invalid response from the upstream server. RFC 9110 §15.6.3.

Common cause

Upstream returned malformed HTTP, the connection broke mid-response, or the application crashed.

When to use it

Reverse proxies (Nginx, Cloudflare, ALB) when the application behind them fails.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 502 Bad Gateway
503 Service Unavailable #

The server is currently unable to handle the request, typically due to maintenance or overload. RFC 9110 §15.6.4.

Common cause

Maintenance window, the queue is full, autoscaler hasn’t caught up, deliberate brown-out.

When to use it

Planned downtime or overload protection. Always set Retry-After so clients can back off.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 503 Service Unavailable
504 Gateway Timeout #

The gateway or proxy did not get a timely response from the upstream server. RFC 9110 §15.6.5.

Common cause

Upstream took longer than the proxy’s configured timeout to respond.

When to use it

Slow application code, blocked database queries, third-party API hangs.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 504 Gateway Timeout
505 HTTP Version Not Supported #

The server does not support the major HTTP version of the request. RFC 9110 §15.6.6.

Common cause

Client speaks HTTP/2 to a server that only does HTTP/1.0, or sends an unrecognised version token.

When to use it

Rare in practice. Misconfigured edges or very old clients.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 505 HTTP Version Not Supported
511 Network Authentication Required #

The client must authenticate to use the network — typically a captive portal. RFC 6585.

Common cause

Hotel or airport Wi-Fi intercepting traffic until login.

When to use it

Captive portals on transient networks. Servers do not normally return this themselves.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 511 Network Authentication Required

What are HTTP status codes?

An HTTP status code is the three-digit number a server returns at the start of every response. It groups into five families: 1xx informational, 2xx success, 3xx redirection, 4xx client error and 5xx server error. The codes are defined in RFC 9110 (the consolidated 2022 spec replacing the older 7230–7235 series), with extensions in RFC 6585 (additional 4xx/5xx), RFC 7725 (451), RFC 4918 (WebDAV) and RFC 8470 (425). Reading the status correctly is the difference between fixing a bug in five minutes and chasing a ghost for an afternoon: a 404 from your CDN means the path is wrong, a 502 from your proxy means the application crashed, and a 401 with no WWW-Authenticate header is a misconfigured backend. This page is a searchable cheat sheet — each card includes the official name, an RFC-grounded description, the typical cause and concrete code snippets you can paste into curl, Python, JavaScript or PHP.

How to use the reference

Type a code or part of a name in the search box, or filter by family using the chips. Each card opens to reveal the technical description, common causes and a tabbed snippet you can adapt. Every code has its own anchor (e.g. #404) so you can deep-link team docs straight to a specific status.

Status code families at a glance

Range Family Meaning
1xxInformationalProvisional responses; rarely seen at the application layer.
2xxSuccessRequest was received, understood and accepted.
3xxRedirectionFurther action is needed (a different URL, cache validation, etc.).
4xxClient errorThe request had a problem (bad input, missing auth, wrong method).
5xxServer errorThe server failed to fulfil an apparently valid request.

Frequently asked questions

Where do these codes come from?
RFC 9110 is the canonical 2022 specification consolidating the older RFC 7231 series. Additional codes live in RFC 6585 (428, 429, 431, 511), RFC 7725 (451), RFC 4918 (WebDAV) and RFC 8470 (425).
Should I use 401 or 403?
401 means "you are not authenticated". 403 means "you are authenticated but not allowed". A 401 must include a WWW-Authenticate header listing accepted schemes; a 403 should not because the credentials are not the issue.
What’s the difference between 301 and 308?
Both signal a permanent redirect. 301 historically rewrites POST to GET in many clients, 308 explicitly preserves the method and body. Use 308 in new APIs.
When does my CDN return 502 vs 504?
502 (Bad Gateway) means the upstream returned malformed data or closed the connection. 504 (Gateway Timeout) means the upstream took too long. CloudFront, Cloudflare and Nginx tag them differently in logs — both indicate an application problem.
Should I return 404 or 410 for deleted content?
Use 410 when the resource was intentionally and permanently removed and you want crawlers to drop it fast. 404 is fine for typos and content that may come back; it’s also a defensible response for resources you don’t want to confirm exist.
Are the snippets safe to copy?
They are minimal templates intended for reading and adapting. Always validate input, handle errors and respect HTTP semantics in your own code — the samples skip those for brevity.