Cache-Control Header Checker
Check how a page or asset is cached — Cache-Control, Expires, ETag, Last-Modified — with the freshness lifetime in plain English and best-practice fixes. Free.
💡 What this checks
- The
Cache-Control,Expires,ETag, andLast-Modifiedheaders for a URL. - How long the response stays fresh (max-age), and whether revalidation is supported.
- Whether static assets are cached aggressively enough for good performance.
Free Cache-Control Header Checker
Check how a page or asset is cached. Enter a URL to see its Cache-Control, Expires, ETag, and Last-Modified headers, how long the response stays fresh, and whether revalidation is supported — with a graded report and best-practice fixes. Free, no sign-up.
Why caching headers matter
HTTP caching headers tell browsers and CDNs how long they may reuse a response instead of downloading it again. Get them right and repeat visits become almost instant, your server load drops, and Core Web Vitals improve. Get them wrong — no caching on static assets, or aggressive caching on pages that change — and you either waste bandwidth or serve stale content. This checker shows exactly how a URL is configured.
The caching headers explained
A few headers control everything:
- Cache-Control — the main policy: max-age, public/private, no-cache, no-store, immutable, and more.
- Expires — a legacy absolute expiry date (Cache-Control takes precedence).
- ETag — a content fingerprint used to revalidate with a cheap 304 Not Modified.
- Last-Modified — the resource's change date, another revalidation signal.
- Age and Vary — how long a shared cache has held the response, and which request headers change it.
How to use the checker
It is one step:
- Enter a URL — a page, or better, a specific asset like a CSS or image file.
- Read the freshness lifetime (from max-age) in plain English.
- Review the findings, from good practices to things worth fixing.
- Apply the recommended Cache-Control policy.
Recommended caching for static assets
For CSS, JavaScript, images, and fonts whose filenames include a version hash (like app.9f2a.css), cache them as hard as possible: Cache-Control: public, max-age=31536000, immutable. Because the filename changes whenever the content changes, there is no risk of serving stale files, and returning visitors reuse everything from cache with zero requests. The immutable directive tells browsers not to even revalidate, saving further round-trips.
Recommended caching for HTML pages
HTML is different, because the URL stays the same while the content updates. Cache pages for a short time, or use no-cache together with an ETag so the browser stores the page but revalidates it on each visit — the server replies with a cheap 304 when nothing has changed, or the new page when it has. Never apply a one-year max-age to an HTML page, or visitors may keep seeing an old version long after you have published changes.
Pro tip
Always pair a caching policy with a revalidation signal (ETag or Last-Modified) so even expired responses can be refreshed with a lightweight 304 instead of a full download. For assets served through a CDN, use s-maxage to set a separate, longer lifetime for the shared cache. To also check compression and other response headers, pair this with our HTTP Response Headers Viewer.
FAQ
Is this cache checker free?
What does max-age mean?
What is the difference between no-cache and no-store?
How should I cache static files like CSS and images?
What are ETag and Last-Modified for?
Which wins, Expires or Cache-Control?
Does caching affect SEO?
Related tools
Pro tip: pair this tool with PageSpeed Insights Checker and View Source Code for a faster SEO workflow.