Directive guide · 28 Oct 2026 · RFC 8246

What does `immutable` change?

immutable is a response directive for a stored response that will not change while fresh. RFC 8246 recommends against conditional validation in that interval; the directive does not set the interval or guarantee uniform browser behavior.

Standards and documentation review only. No browser, cache, endpoint, or provider was tested.

Short answer

For an unchanged static file at a versioned URL, use an explicit freshness lifetime such as max-age=31536000 and add immutable only if the URL’s representation will remain unchanged during that lifetime. When the bytes change, publish a new URL. max-age supplies the example lifetime; immutable does not. RFC 8246 §2 · RFC 9111 §4.2.1

For changed static bytes, publish the changed asset at a new versioned URL; this does not purge the old URL. Choose the guide closest to what you are seeing:

Fresh, stale, and an explicit check

The directive matters only during the response’s freshness lifetime. The boundary is set by the applicable cache policy, not by immutable.

Situation	What the specifications say	Practical reading
Fresh; no explicit override	RFC 8246 says clients SHOULD NOT send a conditional request for a fresh immutable response, including on reload.	The client can reuse the fresh stored representation without conditional validation.
Stale	`immutable` applies only while fresh. Once stale, RFC 8246 says the response should be revalidated as it normally would without the extension.	Use ordinary stale, validator, and request rules; `immutable` is not permanent.
User explicitly asks to check	RFC 8246 says user agents SHOULD ignore `immutable` for a force reload. It also advises an intermediary not to skip validation when the request signals it, such as with `Cache-Control: no-cache`. RFC 9111 treats request directives as advisory for caches.	A force reload can override the optimization. This does not promise a particular network path or response status for every browser or cache.

Versioned asset example

HTTP/1.1 200 OK
Cache-Control: max-age=31536000, immutable

This response states a one-year freshness lifetime with max-age and says the representation will not change while fresh. If a shared cache needs a different freshness lifetime, RFC 9111 gives s-maxage separate precedence; it is absent from this example. The response does not grant shared-storage permission just by containing immutable. Keep the URL stable only for unchanged bytes; publish changed content at a new version or content-hash URL.

What it does not do

It does not set the freshness lifetime: the example’s max-age does.
It does not make a response storable, public, or safe for shared reuse. Storage and privacy directives remain separate.
It does not purge or delete a stored response when a new URL is published.
It does not identify whether a browser, intermediary, or origin supplied a response.
It is not an integrity safeguard: RFC 8246 recommends that clients ignore it for resources outside an authenticated context such as HTTPS.

Browser documentation is not a universal implementation claim

MDN’s current HTTP caching guide says Chrome changed its reload implementation so that subresources are not revalidated on reload. The linked Chromium Blog post is historical (26 Jan 2017) and describes that reload design. This is a Chrome-specific, reload/subresource documentation caveat—not evidence about every browser, version, force-reload mode, or intermediary. RFC 8246 defines the extension’s semantics; no browser was tested here.

Sources: MDN: HTTP caching · Chromium Blog, 26 Jan 2017 · MDN: Cache-Control