Cache Header Checker

See exactly how a URL is cached. Enter an address and this tool reads the live caching headers — Cache-Control, Expires, ETag, Last-Modified, Age and Vary — and gives a plain verdict on whether the response is cacheable, revalidated, or not cached at all. Caching is the biggest lever on repeat-visit speed, and these headers are where it is controlled.

How to use the Cache Header Checker

Enter a URL and press Check cache headers. The tool fetches the resource and reports:

• A verdict — cacheable, revalidated, no cache policy, or explicitly not cached (no-store).
• The individual headers: Cache-Control (with its directives broken out), Expires, ETag, Last-Modified, Age and Vary.
• Any CDN cache status the edge reports (Cloudflare, Vercel, Fastly and similar).

Test a static asset (a CSS, JS, image or font URL) to see a long cache policy, and an HTML page to see a short or revalidating one. The contrast shows whether each resource type is configured the way it should be.

How HTTP caching headers work

HTTP caching lets browsers and CDNs reuse a previously fetched response instead of downloading it again. Done well, a repeat visitor loads most of a page from cache in milliseconds. The behaviour is driven entirely by response headers:

• Cache-Control is the main control. max-age=N sets how many seconds the response stays fresh; no-cache means "store it but revalidate before use"; no-store means "never cache"; private limits it to the browser (not shared CDNs); immutable promises the file will never change so the browser skips revalidation.
• Expires is the older, absolute-date version of freshness. Cache-Control: max-age overrides it where both are present.
• ETag and Last-Modified are validators. When a cached copy goes stale, the browser asks "has it changed since this ETag / date?" and the server can answer 304 Not Modified with no body, saving the download.
• Age tells you how long a shared cache has been holding the response.
• Vary lists the request headers that produce different responses (commonly Accept-Encoding), so caches store the right variant per client.

The right policy depends on the resource. Static assets with hashed filenames (app.4f3a.js) should send a long max-age with immutable, because a new build gets a new filename. HTML usually wants no-cache so users always get the latest markup while still benefiting from cheap 304 revalidation. Getting this wrong is common: either assets are needlessly re-downloaded every visit, or HTML is cached so aggressively that updates do not appear.

Common use cases

• Tuning repeat-visit speed — confirm static assets carry a long, immutable cache policy.
• Debugging stale content — find HTML or APIs cached more aggressively than intended so updates do not show.
• Verifying a CDN — check the edge cache status and confirm resources are actually being cached at the edge.
• Checking revalidation — confirm ETag or Last-Modified is present so the browser can do cheap 304 checks.
• Auditing cacheability — spot resources accidentally marked no-store that could safely be cached.

Static assets vs HTML: two different policies

The single most useful caching habit is to treat fingerprinted assets and HTML differently:

• Hashed static assets (main.8f2c.css, logo.a91.png) — these never change content for a given URL, so cache them hard: Cache-Control: public, max-age=31536000, immutable. The browser reuses them for a year and never even asks the server.
• HTML documents — these change whenever you publish, and they point at the current asset filenames, so they must stay fresh: Cache-Control: no-cache (revalidate every time) or a short max-age. Pair with an ETag so revalidation is a cheap 304.
• Personalised or sensitive responses — anything user-specific should be private (browser only, never a shared CDN) or no-store if it must never be retained.

With this split, a new deploy ships fresh HTML instantly while every unchanged asset keeps loading from cache.