Cache-Control Header

What Is a Cache-Control Header?

A Cache-Control header is an HTTP header that tells browsers, CDNs, and other caches how to store, reuse, or re-validate a web resource. It helps control whether a file should be cached, how long it should stay fresh, and when the cache should check the origin server for a newer version.

Cache-Control is used for many types of resources, including HTML pages, images, videos, CSS files, JavaScript files, API responses, and downloadable assets. Without clear caching instructions, browsers and intermediary caches may make their own assumptions, which can lead to stale content, unnecessary origin requests, or inconsistent performance.

A simple example looks like this:

Cache-Control: public, max-age=31536000

This tells caches that the response can be stored publicly and reused for a set amount of time. The value of max-age is measured in seconds.

How Cache-Control Headers Work

When a browser requests a resource, the server sends back a response. That response can include a Cache-Control header with one or more directives. Each directive gives caching instructions.

For example, a static image might be cached for a long time because it rarely changes. A logged-in account page, on the other hand, should not be stored by shared caches because it may contain private user data.

Cache-Control can appear in both responses and requests. Response headers are more common and tell caches what to do with a delivered resource. Request headers are often created by browsers during refreshes or hard reloads to ask caches for a fresher version.

This makes Cache-Control important for both performance and freshness. It allows teams to reduce repeated downloads while still controlling when users receive updated content.

Common Cache-Control Directives

• max-age defines how long a response remains fresh. For example, max-age=3600 means the cached response can be reused for one hour.
• s-maxage is similar, but it applies to shared caches such as CDNs and proxies. It can override max-age for those shared caches, making it useful when developers want different cache behavior for browsers and CDN edges.
• public means the response can be stored by shared caches. This is common for public images, videos, scripts, stylesheets, and other assets.
• private means the response should only be stored by the user’s browser, not by shared caches. This is useful for personalized content.
• no-cache does not mean “do not store.” It means the response can be stored, but it must be revalidated with the origin server before being reused.
• no-store means the response should not be stored by any cache. This is usually reserved for sensitive data.
• must-revalidate tells caches they cannot reuse stale content without checking with the origin server first.
• immutable tells the browser that a resource will not change while it is fresh. This works best with versioned or hashed asset URLs.
• stale-while-revalidate allows a cache to serve a stale response while it checks for a fresh version in the background.

Why Cache-Control Matters for Media Delivery

Cache-Control is especially important for media-heavy websites and applications. Images and videos can be large, so caching them reduces bandwidth, speeds up delivery, and lowers the load on origin servers.

For example, a product image, thumbnail, or video poster can often be cached at the CDN edge and in the browser. When the same asset is requested again, it loads faster because the user does not need to download it from the origin every time.

However, media assets also change. Teams may replace campaign images, update product photos, regenerate transformations, or remove outdated content. If Cache-Control settings are too aggressive and URLs do not change, users may keep seeing old assets.

This is why Cache-Control works best with versioned URLs and cache invalidation. Long cache durations are useful for assets that have unique versioned URLs. Shorter durations or revalidation rules are safer for content that changes frequently.

Cache-Control Best Practices

Cache-Control headers help you define how browsers, CDNs, and other caches store and reuse media files. A clear caching strategy improves delivery speed while helping users receive the correct version of each asset.

• Set appropriate expiration times: Use longer cache durations for versioned images and videos that rarely change. Choose shorter durations for assets that are updated often.
• Use immutable URLs: Add version numbers or content hashes to asset URLs. This allows you to cache files for longer periods without serving outdated content.
• Apply public and private carefully: Mark shared media as public when CDNs can cache it. Use private for user-specific or sensitive content.
• Use no-cache correctly: This directive allows storage but requires validation before reuse. It does not prevent caching.
• Reserve no-store for sensitive data: Use it when content should never be written to browser or intermediary caches.
• Test cache behavior: Review response headers, CDN logs, and asset updates to confirm that your cache-control rules support reliable video delivery and transformation workflows.

The Bottom Line

The Cache-Control header is one of the most important tools for managing web caching. It tells browsers and CDNs when to store content, when to reuse it, and when to check for updates.

For media delivery, the right Cache-Control strategy can improve load times, reduce bandwidth, and keep visual experiences consistent. The best setup balances long-lived caching for versioned assets with careful revalidation for content that changes often.