Interim responses sent before the final one, while the request is still in progress.
The server has the request headers and the client should go on and send the body.
When you see it: Sent in reply to Expect: 100-continue, so a client can learn that a large upload will be accepted before sending it. curl adds that header to big POST bodies.
The server is switching the connection to the protocol named in the Upgrade header.
When you see it: WebSocket handshakes over HTTP/1.1 (Upgrade: websocket). HTTP/2 and HTTP/3 don't use it.
A WebDAV interim response saying a long-running request is still being worked on.
When you see it: Rarely used: it was left out of the current WebDAV spec (RFC 4918) and most clients ignore it.
Lets the server send Link headers before the final response is ready.
When you see it: Send Link: </app.css>; rel=preload; as=style or rel=preconnect while the backend is still rendering the page, so the browser can start fetching early. Browsers act on it over HTTP/2 and HTTP/3.
SEO and caching: Can shorten Largest Contentful Paint on slow server-rendered pages. Crawlers ignore it.
The request was received, understood and accepted.
The request succeeded. What the body holds depends on the method: the resource for GET, nothing for HEAD, the outcome for POST.
When you see it: The normal success response.
SEO and caching: A "page not found" or empty search page that answers 200 is a soft 404: search engines may index it or report it in Search Console. Return 404 or 410 instead.
The request created one or more new resources.
When you see it: After a POST or PUT that creates something. Include a Location header with the new resource's URL.
The request was accepted for processing, but the processing hasn't finished (and may still fail).
When you see it: Asynchronous work: queued jobs, batch imports, video encoding. Return a URL where the client can check the job's status.
The request succeeded, but a transforming proxy changed the origin server's 200 response.
When you see it: Only proxies send it; an origin server should send 200.
The request succeeded and there is no body to send.
When you see it: DELETE, PUT or PATCH requests that return nothing, autosave endpoints and analytics beacons. A 204 must not carry a body, and browsers stay on the current page.
The request succeeded and the client should reset the document view, for example clear the form that sent it.
When you see it: Rare; browsers don't clear forms on their own when they get it.
The body contains only the byte ranges asked for in the Range header.
When you see it: Resumable downloads and seeking in audio or video. The response carries Content-Range, or a multipart/byteranges body for several ranges.
A WebDAV response whose XML body holds a separate status for each of several resources.
When you see it: WebDAV PROPFIND and other multi-resource operations. Some APIs borrow it for batch results.
Used inside a WebDAV 207 response: the members of this binding were already listed earlier in the same response.
When you see it: WebDAV servers that support bindings, to avoid listing the same collection twice (or looping forever).
The server fulfilled a GET and applied one or more instance manipulations, such as delta encoding, to the response.
When you see it: HTTP delta encoding, which is almost never deployed.
The client has to take another step, usually following the Location header, to complete the request.
The resource has several representations and the client or user should pick one.
When you see it: Rare: content negotiation normally chooses automatically.
The resource has a new permanent URL, given in the Location header.
When you see it: Domain moves, HTTP to HTTPS, renamed URLs. For historical reasons clients may turn a POST into a GET when following it, so use 308 for API endpoints that must keep the method.
SEO and caching: A strong signal: search engines index the new URL and pass ranking signals to it. Keep the redirect in place for at least a year. Browsers cache 301s hard, so test before you ship one.
The resource is temporarily at another URL; clients should keep using the original one.
When you see it: Temporary moves, login redirects, A/B tests. Like 301, browsers turn a POST into a GET when following it; 307 keeps the method.
SEO and caching: Treated as temporary, so the original URL stays indexed, though a 302 left in place for a long time may end up treated as permanent. Use 301 or 308 for permanent moves. Not cached unless Cache-Control or Expires allow it.
Points to another resource, which the client fetches with GET (or HEAD) whatever the original method was.
When you see it: Post/Redirect/Get: after a form POST, redirect to a result page so reloading doesn't submit the form again.
SEO and caching: Search engines treat it as a temporary redirect.
The cached copy the client already has is still valid, so no body is sent.
When you see it: The answer to a conditional GET or HEAD with If-None-Match (ETag) or If-Modified-Since. It must repeat the caching headers a 200 would have had (Cache-Control, ETag, Expires, Vary). Only send it to conditional requests.
SEO and caching: Saves bandwidth and crawl budget: Googlebot sends conditional requests and a 304 tells it the page hasn't changed.
Told the client to repeat the request through the proxy named in Location.
When you see it: Deprecated for security reasons; browsers ignore it. Don't send it.
Was "Switch Proxy" in an early draft and is now reserved.
When you see it: Never send it.
Like 302, but the client must repeat the request to the new URL with the same method and body.
When you see it: Temporary redirects for APIs and form handlers. Browsers also show an internal 307 when HSTS upgrades a link from http:// to https:// without touching the network.
SEO and caching: Temporary, like 302: the original URL stays indexed.
Like 301, but the client must keep the method and body when following it. First defined in RFC 7538.
When you see it: Permanent moves of API endpoints or form targets, and anywhere a 301 would do.
SEO and caching: Search engines treat it the same as 301.
Something is wrong with the request itself: fix it before retrying.
The server won't process the request because of a client error: malformed syntax, invalid framing or unparseable content.
When you see it: Generic input errors when nothing more specific fits (422 is more precise for well-formed but invalid data). Common causes: broken JSON, an invalid query string, corrupted or oversized cookies.
The request has no valid authentication credentials for the resource.
When you see it: A missing, expired or wrong token or password. The response must include a WWW-Authenticate challenge. If the user is logged in but not allowed, send 403.
SEO and caching: Pages behind a 401 are not indexed.
Reserved for future use; it has no standard meaning.
When you see it: Some APIs use it for billing problems, such as an exhausted quota or a declined card.
The server understood the request but refuses to fulfil it, and authenticating again won't help.
When you see it: Logged-in users without permission, IP or country blocks, firewall (WAF) rules, a directory with listing disabled, wrong file permissions. A server may answer 404 instead to hide that the resource exists.
SEO and caching: Not indexed. Don't use 401 or 403 to slow down crawlers; use 429 or 503 for that.
The server has nothing at this URL, or won't say whether it does.
When you see it: Pages that were deleted or never existed, typos and broken links.
SEO and caching: Google drops 404 URLs from its index over time and doesn't penalize a site for having them. Redirect only when there is a real replacement page; redirecting everything to the home page is treated as a soft 404.
The resource exists but doesn't support this method.
When you see it: For example a POST to a read-only URL. The response must include an Allow header listing the supported methods.
The server can't produce a representation that matches the request's Accept headers, and won't send a default.
When you see it: Rare: most servers send a default representation instead. On shared hosting it often comes from ModSecurity blocking a request it considers an attack.
Like 401, but the client has to authenticate with the proxy.
When you see it: Corporate proxies. The response includes a Proxy-Authenticate challenge.
The server didn't receive a complete request in the time it was prepared to wait, and closes the connection.
When you see it: Slow clients and idle keep-alive connections. Clients can repeat the request on a new connection.
The request conflicts with the current state of the resource.
When you see it: Edit conflicts, duplicate unique values (an email already registered), version mismatches. Explain the conflict in the body so the client can resolve it.
The resource was removed on purpose and isn't coming back; there is no forwarding address.
When you see it: Deleted products, expired promotions, content you took down deliberately.
SEO and caching: A slightly stronger signal than 404: search engines may drop the URL a little sooner, but both end up removed from the index.
The server refuses a request with a body but no Content-Length header.
When you see it: Chunked uploads to servers that need the length up front.
A condition in the request headers, such as If-Match or If-Unmodified-Since, turned out false.
When you see it: Optimistic concurrency: refuse a PUT when the resource's ETag changed since the client read it, so nobody overwrites someone else's edit.
The request body is larger than the server is willing to process. Formerly "Payload Too Large".
When you see it: Upload limits, such as nginx's client_max_body_size (1 MB by default) or PHP's upload_max_filesize. Send Retry-After if the limit is temporary.
The URL is longer than the server will interpret.
When you see it: Huge GET queries that should be a POST, or redirect loops that keep appending parameters.
The server doesn't support the body's Content-Type or Content-Encoding.
When you see it: JSON sent without Content-Type: application/json, or an upload in a format the endpoint doesn't take. The response can list what it accepts in Accept or Accept-Encoding.
None of the byte ranges in the Range header fit the resource.
When you see it: Resuming a download of a file that has since shrunk or changed. The response should include Content-Range: bytes */length.
The server, or a proxy on the way, can't meet the request's Expect header.
When you see it: Usually Expect: 100-continue sent through a proxy that doesn't support it. Retrying without the header fixes it.
Reserved. RFC 2324, a 1998 April Fools' joke, defined it as "I'm a teapot", and RFC 9110 keeps it unassigned because some software still sends it.
When you see it: Don't rely on it for anything; send a real 4xx code.
The request reached a server that isn't able to answer for this origin (scheme, host and port). First defined in RFC 7540.
When you see it: HTTP/2 or HTTP/3 connection reuse across host names that share an IP address and certificate but are served by different servers, or an SNI and Host mismatch. Clients can retry on a new connection.
The request is well-formed, with the right content type, but its contents are invalid. Formerly WebDAV's "Unprocessable Entity".
When you see it: Validation errors in APIs: a required field missing, a date in the past, an invalid email. Rails, Laravel and FastAPI use it.
The WebDAV resource is locked.
When you see it: Another client holds a WebDAV lock on the file.
The WebDAV method failed because another action it depended on failed.
When you see it: Part of a PROPPATCH or other multi-step WebDAV request failing.
The server won't process a request that could be replayed, because it arrived in TLS 1.3 early data (0-RTT).
When you see it: Servers and CDNs that accept 0-RTT for safe requests only. The client retries after the TLS handshake completes.
The server refuses to handle the request over the current protocol.
When you see it: The response must include an Upgrade header naming the protocol the client should switch to.
The server requires the request to be conditional.
When you see it: APIs that insist on If-Match for updates, to prevent the lost-update problem.
The client has sent too many requests in a given time: it hit a rate limit.
When you see it: API rate limits and abuse protection. Include Retry-After so clients know when to try again.
SEO and caching: Googlebot treats 429 like a 5xx error and slows down crawling; served for a long time, it can get URLs dropped from the index.
The request headers, or one header, are too large for the server.
When you see it: Usually too many or very large cookies; clearing the site's cookies fixes it for a user.
Access was denied because of a legal demand, such as a court order, government censorship or sanctions.
When you see it: Explain the demand in the body; a Link header with rel="blocked-by" can name the party that applied the block.
The server failed to fulfil a request that may well be valid.
The server hit an unexpected condition that stopped it from fulfilling the request.
When you see it: Uncaught exceptions, crashed scripts, a syntax error in .htaccess, bad file permissions on scripts. The server's error log says what happened.
SEO and caching: Occasional 5xx errors do no harm, but persistent ones make search engines crawl less and eventually drop the affected URLs.
The server doesn't support the functionality needed, typically a method it doesn't recognize at all.
When you see it: Unknown methods. For a method the server knows but the resource doesn't allow, send 405.
A gateway or proxy got an invalid response from the upstream server.
When you see it: The application behind nginx or a load balancer crashed, isn't listening, is on the wrong port, or closed the connection (for example PHP-FPM down).
The server can't handle the request right now because of overload or maintenance; it should work later.
When you see it: Planned maintenance, overload protection, a backend pool with no healthy servers. Send Retry-After with the expected wait.
SEO and caching: The right code for maintenance: search engines retry later and keep pages indexed during a short outage. Serving 503 for more than a few days can get URLs dropped.
A gateway or proxy didn't get a response from the upstream server in time.
When you see it: Slow database queries or long requests that outlast the proxy's timeout (60 seconds by default for nginx's proxy_read_timeout).
The server doesn't support the HTTP major version used in the request.
When you see it: Very old or misbehaving clients.
A server configuration error in transparent content negotiation: the chosen variant is itself set up to negotiate, which would loop.
When you see it: Misconfigured Apache content negotiation; rare.
The server can't store what the request needs it to store.
When you see it: A full disk or exhausted quota on a WebDAV or file storage server.
The CSRF token was missing or expired, usually because the session timed out while a form was open.
When you see it: Reload the page to get a fresh token and submit again.
nginx closed the connection without sending anything; the code appears only in its logs.
When you see it: return 444; drops unwanted traffic, such as requests for unknown host names. Clients see an empty reply.
nginx's internal code for oversized headers; the client receives a 400 "Request Header Or Cookie Too Large" page.
When you see it: Large cookies; raise large_client_header_buffers or trim the cookies.
The client certificate failed verification; the client receives a 400.
When you see it: Mutual TLS setups with ssl_verify_client.
A client certificate was required but none was sent; the client receives a 400.
When you see it: Mutual TLS setups with ssl_verify_client on.
A plain HTTP request arrived on a port that expects TLS; the client receives a 400.
When you see it: Often handled with error_page 497 to redirect to https://.
The client closed the connection before nginx could send the response; it appears only in logs.
When you see it: Users navigating away, or client and load balancer timeouts shorter than the time the backend needs.
The WebDAV server found an infinite loop while processing a request with Depth: infinity.
When you see it: WebDAV bindings that point back at themselves. Some shared hosts also send 508 "Resource Limit Is Reached" when an account exceeds its CPU or process limits, which is a non-standard use.
The hosting account used up its bandwidth allowance.
When you see it: Shared hosting quotas; it clears when the billing period resets or the limit is raised.
The request didn't meet the policy for accessing the resource under the HTTP Extension Framework.
When you see it: Obsolete: the Extension Framework was never adopted and RFC 2774 is now Historic.
The client has to authenticate to get network access.
When you see it: Captive portals on hotel, airport and café Wi-Fi. Origin servers shouldn't send it.
The origin server sent an empty, unknown or unexpected response to Cloudflare.
When you see it: Origin crashes, reset connections, or response headers larger than Cloudflare accepts.
The origin server refused Cloudflare's connection.
When you see it: The web server isn't running, or a firewall blocks Cloudflare's IP ranges.
Cloudflare couldn't complete a TCP connection to the origin in time.
When you see it: An overloaded origin, or a firewall silently dropping Cloudflare's packets.
Cloudflare can't reach the origin server at all.
When you see it: A DNS record pointing at the wrong IP address, or a routing problem.
Cloudflare connected to the origin, but it didn't send an HTTP response in time (100 seconds by default).
When you see it: Long-running requests; move them to a background job or stream progress.
The TLS handshake between Cloudflare and the origin failed.
When you see it: SSL mode Full or Full (strict) with no certificate, no SNI support or no shared cipher on the origin.
In Full (strict) mode, the origin's certificate is invalid.
When you see it: An expired or self-signed origin certificate, or one for a different host name. A Cloudflare Origin CA certificate fixes it.
Cloudflare returns 530 together with a 1xxx error such as 1016 (origin DNS error).
When you see it: Look up the 1xxx number shown on the error page.
Sources: the IANA HTTP Status Code Registry and RFC 9110 (HTTP Semantics), plus the RFCs named on each code. The unofficial group is documented by the vendors themselves.
This page lists every code in the IANA HTTP Status Code Registry, named as in RFC 9110 and the other RFCs that registered them. Each entry explains what the code means, when servers send it, and, where it matters, what it means for search engines and caches. Codes that caches may store without explicit headers are marked "Cacheable by default". A separate group covers unofficial codes from nginx, Cloudflare, Laravel and shared hosts, which are not standards.
#404 at the end of the page URL.For web pages either works: search engines treat 301 and 308 as permanent and 302 and 307 as temporary. The difference is the method: clients may turn a POST into a GET when following a 301 or 302, but must keep it for 307 and 308, so APIs should use those.
Both remove the URL from search results in time; 410 says the removal is deliberate and may be processed a little sooner. Redirect only to a genuine replacement.
503 with a Retry-After header. Search engines retry later and keep your pages indexed during a short outage.
A joke from a 1998 April Fools' RFC. RFC 9110 marks it unused and reserved.