Cache-Control Checker
Check how a public URL instructs browsers and shared caches. Parse Cache-Control, CDN-specific policy, Age, Expires, validators and Vary, then compare two requests for live cache evidence.
Browser + CDN policyTwo-request comparisonRaw header evidenceNo signup
Fetching the URL twice and analyzing cache headers…
Cache report
Cache policy analysis
Policy
Browser vs shared cache
Freshness rules are separated because browsers and CDNs can follow different TTLs.
Repeated request
First vs second request
Point-in-time evidence from two ordinary GET requests to the same final URL.
Headers
Cache-related response headers
Standard validators, freshness headers and detected CDN/proxy cache fields.
Diagnostics
Findings and actions
No artificial performance score—each item is tied to a concrete response signal.
Redirect path
Methodology and limitations
HTTP caching explained
What a Cache-Control checker should tell you
“Cached” is not one state. Browser freshness, shared/CDN freshness, validation and live edge status are separate signals.
max-age
max-age defines how long a response stays fresh for ordinary caches. The freshness clock relates to when the response was generated, and an Age value can reduce remaining freshness.
s-maxage
s-maxage applies to shared caches such as CDNs and can override max-age for those caches. This allows a browser TTL and edge TTL to differ.
no-cache vs no-store
no-cache allows storage but requires revalidation before reuse. no-store tells caches not to store the response. They are not interchangeable.
ETag and Last-Modified
Validators let clients ask whether stale content changed. If it did not, the server can return 304 Not Modified instead of sending the full representation again.
Age
Age indicates how long a response has spent in a proxy cache. A positive Age value can be evidence of shared-cache reuse, but absence of Age does not prove there is no CDN.
Vary
Vary changes the cache key based on named request headers. Vary: * prevents normal reuse because unspecified factors influenced the representation.
Why the tool makes two requests
The second request can reveal a CDN HIT, a positive Age, or a vendor-specific cache-status transition. A repeated MISS is not automatically a problem: the object may be cold, intentionally bypassed, private, dynamic or keyed differently by headers, cookies or edge location.
Static assets and HTML should not use the same policy blindly
Fingerprint/versioned CSS, JavaScript, fonts and images are often good candidates for long-lived caching and immutable. HTML, APIs and personalized responses usually need more conservative or revalidation-based policies. The correct policy depends on how the URL changes when its content changes.
CDN-specific cache headers
This checker recognizes common evidence such as CF-Cache-Status, X-Cache, X-Vercel-Cache, X-Nextjs-Cache, generic X-Cache-Status, X-CDNJS-Cache and Age. Vendor headers are interpreted as evidence, not as a universal cache standard.
Related tools
Primary references
MDN Cache-Control · MDN HTTP caching guide · Cloudflare cache-status troubleshooting