What is the difference between no-cache and no-store?

no-cache means the response may be stored but must be revalidated with the origin before serving — it does not mean 'do not cache'. no-store means the response must not be stored in any cache at all. For sensitive private data, use no-store. For content that changes frequently but should still benefit from conditional requests, use no-cache.

What does stale-while-revalidate do?

stale-while-revalidate=N allows a cache to serve a stale response for up to N seconds while asynchronously fetching a fresh copy from the origin in the background. The user gets an immediate response (even if slightly stale) while the cache refreshes behind the scenes. It reduces latency on frequently changing content without blocking the response on a synchronous origin round-trip.

When should I use immutable?

immutable should only be used on versioned or hashed assets where the URL changes whenever the content changes (e.g. main.a1b2c3.js). It tells the browser not to send revalidation requests during the freshness window. Paired with a long max-age (max-age=31536000), this eliminates all revalidation network traffic for truly immutable assets. Do not use it on HTML pages or any URL that can serve updated content without a URL change.

Can a CDN cache longer than the browser?

Yes — this is exactly what s-maxage enables. Set max-age=0 for the browser and s-maxage=86400 for the CDN, and the CDN serves from cache for 24 hours while the browser always revalidates. This is a common pattern for HTML pages: keep browser freshness short to avoid stale page content, while the CDN absorbs the volume with a longer TTL.

What does the Age header tell me?

Age tells you how many seconds ago the shared cache (CDN or proxy) fetched the response from the origin. If Age=1234 and s-maxage=3600, the remaining freshness is 2366 seconds. If Age exceeds the max-age or s-maxage value, the response is stale in the shared cache and should have been revalidated.

Should HTML pages use the same cache policy as static assets?

No. Static hashed assets (JS, CSS, images with content hashes in the URL) are safe with long max-age and immutable, because the URL changes when content changes. HTML pages reference those assets and change more frequently — a long browser max-age on HTML risks users seeing stale pages that reference old asset URLs. Use a short max-age or max-age=0 for HTML, optionally with s-maxage for CDN control.

Is stale-if-error useful in production?

Yes, especially for high-traffic sites where brief origin outages should not cause visible errors. stale-if-error=N allows the cache to serve a stale response for up to N seconds if the origin returns a 5xx error or is unreachable. For non-sensitive public content, this provides meaningful resilience. Avoid it for real-time data or financial information where stale content could cause harm.

All tools

Cache-Control Analyzer & CDN Config Builder

Q: What is the difference between max-age and s-maxage?

max-age controls freshness for private caches (browser). s-maxage controls freshness for shared caches (CDNs, reverse proxies) and overrides max-age for those shared caches. Setting max-age=0, s-maxage=86400 means the browser always revalidates but the CDN caches for 24 hours.

Translate Cache-Control headers into plain English, visualize browser vs CDN behavior, and generate optimized caching configs for real deployment targets.

Cache-Control *

CDN-Cache-Control (optional)

Optional debug headers (Expires, ETag, Last-Modified, Age, Vary)

Expires

ETag

Last-Modified

Age

Vary

This tool runs entirely in your browser. No URLs are fetched, no headers are sent to a server, and no input data is stored between sessions. All analysis and config generation is local.

Overview

HTTP caching is one of the most impactful — and most misunderstood — performance levers available to web developers. The same Cache-Control header can mean very different things depending on which layer of the stack is reading it. Browser caches, CDN edge nodes, and reverse proxies each interpret the same directives through different lenses, and writing a header that does what you actually intend requires understanding those distinctions precisely.

The most common source of confusion is the difference between private and shared cache behavior. max-age controls how long a browser caches a response. s-maxage overrides that value for shared caches like CDNs — letting you set a short browser freshness window alongside a long edge cache lifetime. Without knowing this distinction, it is easy to accidentally let CDNs cache private user responses, or to underuse edge caching when it would dramatically reduce origin load.

Stale content, missed invalidations, and unnecessary origin traffic are often symptoms of caching headers written by trial and error rather than designed intentionally. Understanding what stale-while-revalidate, no-cache, immutable, and must-revalidate actually mean — and where they apply — is the difference between a caching strategy that works and one that quietly causes problems.

Use cases

When to use it

Translating Cache-Control directives into plain Englishpaste any header value and get a per-directive explanation covering target (browser vs CDN), freshness window, and behavioral implications.
Visualizing browser vs CDN cache behaviorthe request flow visualizer shows which layer handles the request (browser fresh hit, CDN fresh hit, or origin reached) for a given set of directives.
Detecting conflicting or redundant directivesthe issue detector flags combinations like no-store with max-age, public alongside private, immutable without meaningful max-age, and stale-while-revalidate with must-revalidate.
Building safe caching strategies for different asset typespresets for hashed static assets (max-age=31536000, immutable), HTML documents (short max-age, s-maxage + stale-while-revalidate), dynamic APIs (private, must-revalidate), and sensitive data (no-store).
Generating deployable server configurationthe builder generates copy-ready snippets for Nginx, Apache, Vercel JSON headers, Next.js config headers(), Express middleware, and Cloudflare cache rules.
Understanding Age, ETag, Vary, and Last-Modified contextoptional debug header fields explain whether a response is a cache hit, how old the cached copy is, whether validators support efficient revalidation, and how Vary affects cache key behavior.

When it's not enough

Live URL fetching or real CDN inspectionthis is a simulation and analysis tool. It does not fetch live responses or query CDN APIs. Use curl -I or browser DevTools to inspect real response headers, then paste them here for analysis.
Treating all CDNs as identicalCDN behavior varies by platform. Cloudflare, Fastly, and Vercel Edge Network each have their own rules about when they honor or override Cache-Control directives. Always test against your specific platform.
Using immutable on content without URL versioningimmutable tells the browser not to revalidate during the freshness window. If the URL can serve updated content without a URL change, immutable will cause users to see stale content for the entire freshness period.

How to use it

1
Paste your header or start from a preset
In Header Analyzer mode, paste the Cache-Control value from your server response. In Strategy Builder mode, click a preset to pre-populate settings for your asset type.
2
Review the plain-English directive breakdown
Each directive shows its plain-English meaning, whether it applies to browser only or shared/CDN caches, and the freshness duration in human-readable form.
3
Check the Issues tab for conflicts
The tool detects redundant, conflicting, or risky combinations — such as no-store alongside freshness directives, or public without s-maxage when CDN caching is intended.
4
Inspect the request flow
The Cache Flow tab visualizes which layer handles requests: browser from cache, CDN from cache, or origin. Shows stale-while-revalidate and stale-if-error states where applicable.
5
Copy deployment-ready snippets
The Server Snippets tab in Builder mode generates Nginx, Apache, Vercel, Next.js, Express, and Cloudflare configurations. Copy the relevant snippet and apply to your deployment.

Common errors and fixes

Confusing no-cache with no-store

no-cache does not mean 'do not cache'. It means the response may be stored but must be revalidated with the origin before serving. no-store means the response must not be stored at all. If you need to prevent caching entirely, use no-store. If you want revalidation on every request, use no-cache.

Missing s-maxage when CDN caching is intended

Without s-maxage, CDNs use max-age for shared cache freshness. If you want CDNs to cache for 24 hours but browsers to only cache for 60 seconds, add both: max-age=60, s-maxage=86400. This is the most impactful lever for separating browser and edge cache lifetimes.

Using immutable on content without URL versioning

immutable prevents browser revalidation during the freshness window. It is safe only when the URL is guaranteed to change if the content changes (e.g. main.a1b2c3.js). Do not use immutable on HTML pages or any URL that may serve updated content without a URL change.

Long browser max-age on HTML pages

HTML pages reference versioned assets. A long browser max-age on the HTML itself (e.g. max-age=86400) means users may see a stale HTML that references old asset URLs even after a deployment. Use max-age=0 or a very short freshness for HTML, and control CDN caching separately with s-maxage.

stale-while-revalidate without a freshness baseline

stale-while-revalidate extends the window during which a stale response may be served. Without max-age or s-maxage defining when the response goes stale, the SWR window has nothing to extend. Add a max-age or s-maxage alongside SWR.

Assuming stale-while-revalidate works the same everywhere

Browser support for stale-while-revalidate is broad but CDN support varies. Some CDN platforms require specific configuration to honor it, while others apply it automatically. Verify behavior on your specific deployment platform.

Missing validators on content that revalidates frequently

ETag and Last-Modified allow conditional requests (If-None-Match, If-Modified-Since). Without validators, a revalidation request must return the full response even if content hasn't changed. Validators enable 304 Not Modified responses which save bandwidth and reduce latency.

Frequently asked questions

SRI Hash Generator & Integrity Policy Helper URL Indexability Inspector Image Optimizer HTTP Headers Checker CSP Evaluator & Violation Report Parser All developer tools

What is the difference between max-age and s-maxage?

max-age controls freshness for private caches — primarily the user's browser. It tells the browser how many seconds it may serve the cached response without revalidating.

s-maxage controls freshness for shared caches — CDNs and reverse proxies. When s-maxage is present, shared caches ignore max-age entirely. This lets you set a short browser freshness (e.g. max-age=0) while keeping the CDN copy fresh for much longer (e.g. s-maxage=86400).

This is the most important directive pair for CDN-first architectures. Without s-maxage, your CDN may be applying the same aggressive freshness policy as the browser — or not caching at all — depending on the platform's defaults.

Cache-Control directive cheat sheet

Directive	Target	Effect	Common use case
no-store	Browser + CDN	No storage in any cache — most restrictive	Sensitive data: auth responses, PII, private session content
no-cache	Browser + CDN	May cache but must revalidate before serving	Content that changes frequently but can be revalidated cheaply
public	Browser + CDN	Allows storage in shared caches even for auth'd responses	Any static or semi-static content safe for shared caching
private	Browser only	Restricts storage to browser — shared caches must not store	User-specific pages, dashboard content, personalised responses
max-age=N	Browser (primary)	Fresh for N seconds in browser; CDN fallback if no s-maxage	Static assets, CSS, JS, fonts
s-maxage=N	CDN only	Overrides max-age for shared caches — CDN fresh for N seconds	Control CDN lifetime independently of browser lifetime
immutable	Browser	No revalidation requests during freshness window	Versioned/hashed assets (main.a1b2c3.js) with long max-age
stale-while-revalidate=N	Browser + CDN	Serve stale for N seconds while fetching fresh in background	HTML, dynamic pages — reduce latency without fully stale risk
stale-if-error=N	Browser + CDN	Serve stale for N seconds if origin is unreachable or errors	Resilience layer for high-traffic or flaky origin servers

Inspecting cache headers with curl

# Fetch response headers only (no body)
curl -I https://example.com/

# Key headers to inspect:
# Cache-Control: public, max-age=3600, s-maxage=86400
# Age: 1234          ← seconds in shared cache; remaining freshness = s-maxage - Age
# ETag: "33a64df..."  ← enables If-None-Match conditional revalidation
# Last-Modified: ...  ← enables If-Modified-Since conditional revalidation
# Vary: Accept-Encoding  ← cache key includes this header — multiple entries per URL

Age — how long the shared-cache copy has been stored. Remaining freshness = s-maxage or max-age minus Age.
ETag / Last-Modified — validators that enable efficient revalidation (304 Not Modified) rather than a full response round-trip.
Vary — adds header names to the cache key. Vary: Accept-Encoding is normal. Vary: * effectively disables shared caching.

Cache-Control Analyzer & CDN Config Builder

Overview

Use cases

How to use it

Common errors and fixes

Frequently asked questions

What is the difference between max-age and s-maxage?

What is the difference between no-cache and no-store?

What does stale-while-revalidate do?

When should I use immutable?

Can a CDN cache longer than the browser?

What does the Age header tell me?

Should HTML pages use the same cache policy as static assets?

Is stale-if-error useful in production?

Related

What is the difference between max-age and s-maxage?

Cache-Control directive cheat sheet

Inspecting cache headers with curl