Cache-Control header

Syntax

Cache-Control: <directive><directive>...

Cache directives follow these rules:

• Caching directives are case-insensitive. Howeverlowercase is recommended because some implementations do not recognize uppercase directives.
• Multiple directives are permitted and must be comma-separated (e.g.Cache-control: max-age=180public).
• Some directives have an optional argument. When an argument is providedit is separated from the directive name by an equals symbol (=). Typicallyarguments for the directives are integers and are therefore not enclosed in quote characters (e.g.Cache-control: max-age=12).

Cache directives

The following table lists the standard Cache-Control directives:

Note: Check the compatibility table for their support; user agents that don't recognize them should ignore them.

Vocabulary

This section defines the terms used in this documentsome of which are from the specification.

(HTTP) cache

Implementation that holds requests and responses for reusing in subsequent requests. It can be either a shared cache or a private cache.

Shared cache

Cache that exists between the origin server and clients (e.g.ProxyCDN). It stores a single response and reuses it with multiple users — so developers should avoid storing personalized contents to be cached in the shared cache.

Private cache

Cache that exists in the client. It is also called local cache or browser cache. It can store and reuse personalized content for a single user.

Store response

Store a response in caches when the response is cacheable. Howeverthe cached response is not always reused as-is. (Usually"cache" means storing a response.)

Reuse response

Reuse cached responses for subsequent requests.

Revalidate response

Ask the origin server whether or not the stored response is still fresh. Usuallythe revalidation is done through a conditional request.

Fresh response

Indicates that the response is fresh. This usually means the response can be reused for subsequent requestsdepending on request directives.

Stale response

Indicates that the response is a stale response. This usually means the response can't be reused as-is. Cache storage isn't required to remove stale responses immediately because revalidation could change the response from being stale to being fresh again.

Age

The time since a response was generated. It is a criterion for whether a response is fresh or stale.

Directives

This section lists directives that affect caching — both response directives and request directives.

Response Directives

max-age

The max-age=N response directive indicates that the response remains fresh until N seconds after the response is generated.

Cache-Control: max-age=604800

Indicates that caches can store this response and reuse it for subsequent requests while it's fresh.

Note that max-age is not the elapsed time since the response was received; it is the elapsed time since the response was generated on the origin server. So if the other cache(s) — on the network route taken by the response — store the response for 100 seconds (indicated using the Age response header field)the browser cache would deduct 100 seconds from its freshness lifetime.

If the max-age value is negative (for example-1) or isn't an integer (for example3599.99)then the caching behavior is unspecified. Caches are encouraged to treat the value as if it were 0 (this is noted in the Calculating Freshness Lifetime section of the HTTP specification).

Cache-Control: max-age=604800
Age: 100

s-maxage

The s-maxage response directive indicates how long the response remains fresh in a shared cache. The s-maxage directive is ignored by private cachesand overrides the value specified by the max-age directive or the Expires header for shared cachesif they are present.

Cache-Control: s-maxage=604800

no-cache

The no-cache response directive indicates that the response can be stored in cachesbut the response must be validated with the origin server before each reuseeven when the cache is disconnected from the origin server.

Cache-Control: no-cache

If you want caches to always check for content updates while reusing stored contentno-cache is the directive to use. It does this by requiring caches to revalidate each request with the origin server.

Note that no-cache does not mean "don't cache". no-cache allows caches to store a response but requires them to revalidate it before reuse. If the sense of "don't cache" that you want is actually "don't store"then no-store is the directive to use.

must-revalidate

The must-revalidate response directive indicates that the response can be stored in caches and can be reused while fresh. If the response becomes staleit must be validated with the origin server before reuse.

Typicallymust-revalidate is used with max-age.

Cache-Control: max-age=604800must-revalidate

HTTP allows caches to reuse stale responses when they are disconnected from the origin server. must-revalidate is a way to prevent this from happening - either the stored response is revalidated with the origin server or a 504 (Gateway Timeout) response is generated.

proxy-revalidate

The proxy-revalidate response directive is the equivalent of must-revalidatebut specifically for shared caches only.

no-store

The no-store response directive indicates that any caches of any kind (private or shared) should not store this response.

Cache-Control: no-store

private

The private response directive indicates that the response can be stored only in a private cache (e.g.local caches in browsers).

Cache-Control: private

You should add the private directive for user-personalized contentespecially for responses received after login and for sessions managed via cookies.

If you forget to add private to a response with personalized contentthen that response can be stored in a shared cache and end up being reused for multiple userswhich can cause personal information to leak.

public

The public response directive indicates that the response can be stored in a shared cache. Responses for requests with Authorization header fields must not be stored in a shared cache; howeverthe public directive will cause such responses to be stored in a shared cache.

Cache-Control: public

In generalwhen pages are under Basic Auth or Digest Auththe browser sends requests with the Authorization header. This means that the response is access-controlled for restricted users (who have accounts)and it's fundamentally not shared-cacheableeven if it has max-age.

You can use the public directive to unlock that restriction.

Cache-Control: publicmax-age=604800

Note that s-maxage or must-revalidate also unlock that restriction.

If a request doesn't have an Authorization headeror you are already using s-maxage or must-revalidate in the responsethen you don't need to use public.

must-understand

The must-understand response directive indicates that a cache should store the response only if it understands the requirements for caching based on status code.

must-understand should be coupled with no-store for fallback behavior.

Cache-Control: must-understandno-store

If a cache doesn't support must-understandit will be ignored. If no-store is also presentthe response isn't stored.

If a cache supports must-understandit stores the response with an understanding of cache requirements based on its status code.

no-transform

Some intermediaries transform content for various reasons. For examplesome convert images to reduce transfer size. In some casesthis is undesirable for the content provider.

no-transform indicates that any intermediary (regardless of whether it implements a cache) shouldn't transform the response contents.

immutable

The immutable response directive indicates that the response will not be updated while it's fresh.

Cache-Control: publicmax-age=604800immutable

A modern best practice for static resources is to include version/hashes in their URLswhile never modifying the resources — but insteadwhen necessaryupdating the resources with newer versions that have new version-numbers/hashesso that their URLs are different. That's called the cache-busting pattern.

<script src="https://example.com/react.0.0.0."></script>

When a user reloads the browserthe browser will send conditional requests for validating to the origin server. But it's not necessary to revalidate those kinds of static resources even when a user reloads the browserbecause they're never modified. immutable tells a cache that the response is immutable while it's fresh and avoids those kinds of unnecessary conditional requests to the server.

When you use a cache-busting pattern for resources and apply them to a long max-ageyou can also add immutable to avoid revalidation.

stale-while-revalidate

The stale-while-revalidate response directive indicates that the cache could reuse a stale response while it revalidates it to a cache.

Cache-Control: max-age=604800stale-while-revalidate=86400

In the example abovethe response is fresh for 7 days (604800s). After 7 days it becomes stalebut the cache is allowed to reuse it for any requests that are made in the following day (86400s)provided that they revalidate the response in the background.

Revalidation will make the cache be fresh againso it appears to clients that it was always fresh during that period — effectively hiding the latency penalty of revalidation from them.

If no request happened during that periodthe cache became stale and the next request will revalidate normally.

stale-if-error

The stale-if-error response directive indicates that the cache can reuse a stale response when an upstream server generates an erroror when the error is generated locally. Herean error is considered any response with a status code of 500502503or 504.

Cache-Control: max-age=604800stale-if-error=86400

In the example abovethe response is fresh for 7 days (604800s). Afterwardsit becomes stalebut can be used for an extra 1 day (86400s) when an error is encountered.

After the stale-if-error period passesthe client will receive any error generated.

Request Directives

no-cache

The no-cache request directive asks caches to validate the response with the origin server before reuse.

Cache-Control: no-cache

no-cache allows clients to request the most up-to-date response even if the cache has a fresh response.

Browsers usually add no-cache to requests when users are force reloading a page.

no-store

The no-store request directive allows a client to request that caches refrain from storing the request and corresponding response — even if the origin server's response could be stored.

Cache-Control: no-store

max-age

The max-age=N request directive indicates that the client allows a stored response that is generated on the origin server within N seconds — where N may be any non-negative integer (including 0).

Cache-Control: max-age=10800

In the case aboveif the response with Cache-Control: max-age=10800 was generated more than 3 hours ago (calculated from max-age and the Age header)the cache couldn't reuse that response.

Many browsers use this directive for reloadingas explained below.

Cache-Control: max-age=0

max-age=0 is a workaround for no-cachebecause many old (HTTP/1.0) cache implementations don't support no-cache. Recently browsers are still using max-age=0 in "reloading" — for backward compatibility — and alternatively using no-cache to cause a "force reloading".

If the max-age value is negative (for example-1) or isn't an integer (for example3599.99)then the caching behavior is unspecified. Caches are encouraged to treat the value as if it were 0.

max-stale

The max-stale=N request directive indicates that the client allows a stored response that is stale within N seconds. If no N value is specifiedthe client will accept a stale response of any age.

Cache-Control: max-stale=3600

For examplea request with the header above indicates that the browser will accept a stale response from the cache that has expired within the last hour.

Clients can use this header when the origin server is down or too slow and can accept cached responses from caches even if they are a bit old.

Note that the major browsers do not support requests with max-stale.

min-fresh

The min-fresh=N request directive indicates that the client allows a stored response that is fresh for at least N seconds.

Cache-Control: min-fresh=600

In the case aboveif the response with Cache-Control: max-age=3600 was stored in caches 51 minutes agothe cache couldn't reuse that response.

Clients can use this header when the user requires the response to not only be freshbut also requires that it won't be updated for a period of time.

Note that the major browsers do not support requests with min-fresh.

no-transform

Same meaning that no-transform has for a responsebut for a request instead.

only-if-cached

The client indicates that an already-cached response should be returned. If a cache has a stored responseeven a stale oneit will be returned. If no cached response is availablea 504 Gateway Timeout response will be returned.

stale-if-error

The stale-if-error request directive indicates that the browser is interested in receiving stale content on error from any intermediate server for a particular origin. This is not supported by any browser (see Browser compatibility).

Use Cases

Preventing storing

If you don't want a response stored in cachesuse the no-store directive.

Cache-Control: no-store

Note that no-cache means "it can be stored but don't reuse before validating" — so it's not for preventing a response from being stored.

Cache-Control: no-cache

In theoryif directives are conflictedthe most restrictive directive should be honored. So the example below is basically meaningless because privateno-cachemax-age=0 and must-revalidate conflict with no-store.

# conflicted
Cache-Control: privateno-cacheno-storemax-age=0must-revalidate

# equivalent to
Cache-Control: no-store

Caching static assets with "cache busting"

When you build static assets with versioning/hashing mechanismsadding a version/hash to the filename or query string is a good way to manage caching.

For example:

<!-- index.html -->
<script src="/assets/react.min."></script>
<img src="/assets/hero.png" width="900" height="400" />

The React library version will change when you update the libraryand hero.png will also change when you edit the picture. So those are hard to store in a cache with max-age.

In such a caseyou could address the caching needs by using a specificnumbered version of the libraryand including the hash of the picture in its URL.

<!-- index.html -->
<script src="/assets/react.0.0.0min."></script>
<img src="/assets/hero.png?hash=deadbeef" width="900" height="400" />

You can add a long max-age value and immutable because the content will never change.

# /assets/*
Cache-Control: max-age=31536000immutable

When you update the library or edit the picturenew content should have a new URLand caches aren't reused. That is called the "cache busting" pattern.

Use a no-cache to make sure that the HTML response itself is not cached. no-cache could cause revalidationand the client will correctly receive a new version of the HTML response and static assets.

# /index.html
Cache-Control: no-cache

Note: If index.html is controlled under Basic Authentication or Digest Authenticationfiles under /assets are not stored in the shared cache. If /assets/ files are suitable for storing in a shared cacheyou also need one of publics-maxage or must-revalidate.

Up-to-date contents always

For content that's generated dynamicallyor that's static but updated oftenyou want a user to always receive the most up-to-date version.

If you don't add a Cache-Control header because the response is not intended to be cachedthat could cause an unexpected result. Cache storage is allowed to cache it heuristically — so if you have any requirements on cachingyou should always indicate them explicitlyin the Cache-Control header.

Adding no-cache to the response causes revalidation to the serverso you can serve a fresh response every time — or if the client already has a new onejust respond 304 Not Modified.

Cache-Control: no-cache

Most HTTP/1.0 caches don't support no-cache directivesso historically max-age=0 was used as a workaround. But only max-age=0 could cause a stale response to be reused when caches disconnected from the origin server. must-revalidate addresses that. That's why the example below is equivalent to no-cache.

Cache-Control: max-age=0must-revalidate

But for nowyou can simply use no-cache instead.

Clearing an already-stored cache

There are no cache directives for clearing already-stored responses from caches on intermediate servers.

Imagine that clients/caches store a fresh response for a pathwith no request flight to the server. There is nothing a server could do to that path.

Clear-Site-Data: cache can be used to clear every stored response for a site in the browser cacheso use this with care. Note that this will not affect shared or intermediate caches.

Specifications

Browser compatibility

See also

• HTTP caching
• Caching Tutorial for Web Authors and Webmasters
• Caching best practices & max-age gotchas
• Cache-Control for Civilians
• RFC 9111 – HTTP Caching
• RFC 5861 – HTTP Cache-Control Extensions for Stale Content
• RFC 8246 – HTTP Immutable Responses