Free Cache-Control Header Analyzer

The Cache-Control Header Analyzer is a free online tool that parse and understand cache-control headers. visual builder and best practice recommendations. It runs entirely in your browser with no installation or sign-up needed.

All Cache-Control directives including max-age, no-cache, no-store, public, private, must-revalidate, and more.

Yes — toggle directives in the builder mode to generate the header string.

Yes, completely free.

Absolutely. The Cache-Control Header Analyzer processes everything client-side in your browser. No data is uploaded to or stored on any server. Your content remains private on your device at all times.

Yes, the Cache-Control Header Analyzer is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the Cache-Control Header Analyzer in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

The Cache-Control Header Analyzer works in all modern browsers including Chrome, Firefox, Safari, Edge, and Opera. For the best experience, use the latest version of your preferred browser.

Both set a freshness lifetime in seconds, but they target different caches. max-age tells every cache — including the visitor's browser — how long the response stays fresh before it must be re-fetched or revalidated. s-maxage applies only to shared caches like CDNs and proxies, and when present it overrides max-age for those caches while leaving the browser's max-age untouched. This lets you cache a response aggressively at the CDN edge while keeping a shorter or different lifetime in the browser, for example public, max-age=3600, s-maxage=86400 for a one-hour browser cache and a one-day edge cache. This analyzer reports the browser cache and the CDN cache as two separate badges, so paste your header above to see exactly how long each layer will hold the response.

Despite the similar names, these directives do opposite things. no-store forbids caching entirely: neither the browser nor any CDN may keep a copy, so every request goes back to the origin. It is the right choice for sensitive responses like banking pages or personal account data. no-cache does allow the response to be stored, but the cache must revalidate it with the origin server before serving it again, so the user always gets verified-fresh content without a full re-download when nothing has changed. A common pattern is no-cache for HTML so new asset references appear immediately after a deploy, and no-store only where privacy demands it. Paste a header above and the analyzer labels each directive by category — freshness, revalidation, or audience — so the behavior is clear at a glance.

max-age is always expressed in seconds, and 31,536,000 seconds equals exactly one year (60 x 60 x 24 x 365). It is the conventional maximum because most caching guidance treats a year as effectively permanent. You see it paired with immutable on fingerprinted static assets — files whose names include a content hash, like app.4f2a9c.js — because a new build produces a new filename, so the old file never needs to change and can be cached for as long as possible. The immutable directive additionally tells browsers not to send revalidation requests on reload during that window. Computing durations by hand is error-prone, so this tool converts any max-age or s-maxage value back into readable units like hours and days, letting you sanity-check a header before shipping it. Paste one above to decode it instantly.

Stale content after a deploy almost always traces back to a too-aggressive Cache-Control header on the HTML document. If the page was sent with a long max-age and no revalidation directive, browsers and CDNs keep serving the cached copy — along with its old references to your CSS and JavaScript — until that lifetime expires, so users never pick up the fix. The safe fix is to serve HTML with no-cache (or a very short max-age plus must-revalidate) so it is revalidated on every visit and immediately reflects new asset references, while keeping long, immutable caching only on hashed static files. Remember that CDN edge caches obey s-maxage independently, so a stale edge can outlast a fresh browser. Paste the page's Cache-Control header above to see whether it is being cached too long.

stale-while-revalidate lets a cache serve a slightly outdated response instantly while it fetches a fresh copy from the origin in the background, so the next visitor gets the update without anyone waiting on a slow round-trip. You set a window in seconds — for example public, max-age=300, stale-while-revalidate=60 means the response is fresh for five minutes, then may be served stale for up to one more minute while it refreshes behind the scenes. It is ideal for content that can tolerate brief staleness, like CDN-cached pages and API responses where perceived speed matters more than absolute freshness. A related directive, stale-if-error, serves a stale copy when the origin returns an error, improving resilience. Paste a header containing either directive above and the analyzer explains the exact behavior and timing.