Cache headers checker. A-F caching grade.
Paste raw response headers. We parse Cache-Control directives, validate ETag/Last-Modified pairs, flag missing or conflicting headers, and produce a letter-grade caching audit aligned with RFC 9111.
Paste HTTP response headers. The checker parses every Cache-Control directive (max-age, s-maxage, public, private, no-cache, no-store, must-revalidate, immutable, stale-while-revalidate), validates ETag and Last-Modified, checks Expires + Pragma legacy headers, and produces an A-F caching grade per RFC 9111.
Sources used
- RFC 9111 — HTTP Caching (canonical spec)
- RFC 5861 — stale-while-revalidate / stale-if-error
- RFC 8246 — immutable directive
- MDN Cache-Control reference
- MDN ETag reference
- web.dev HTTP cache guide — practical setup recommendations
No data is sent to any external service. Parsing happens entirely in your browser; the source links above are RFC + reference documentation only.
Privacy: parsing happens in your browser. Nothing is sent or logged.
Caching is a directive language.
HTTP caching is governed by RFC 9111 via the Cache-Control response header and its directive vocabulary: max-age, s-maxage, public, private, no-cache, no-store, must-revalidate, immutable, stale-while-revalidate. Each directive has a precise meaning that browsers and CDNs implement consistently. The checker above parses every directive, validates ETag and Last-Modified pairing, flags conflicting directives, and produces a letter-grade audit. Most production caching bugs are misuse of no-cache (often confused with no-store), missing s-maxage on public responses, or missing immutable on versioned assets.
Three rules of thumb. Versioned static assets (file.abc123.js): max-age=31536000, immutable — content-addressed URLs never need revalidation. HTML: short max-age (300s) + stale-while-revalidate (86400s) — fast for repeat visits, freshness on background refresh. API JSON: no-store unless explicitly cacheable; if cacheable, short max-age + private to keep responses out of CDN. The web.dev HTTP cache guide is the canonical practical reference.
Tools in the same cluster: HTTP Headers Checker for the broader headers grade. CDN Detector for the edge tier (which respects s-maxage). Compression Detector for Vary: Accept-Encoding correctness.
Five answers.
What headers control HTTP caching?
Cache-Control is the modern primary header (RFC 9111). It carries directives: max-age (browser cache TTL in seconds), s-maxage (CDN/proxy TTL), public (cacheable by any cache), private (browser only, not CDN), no-cache (revalidate before use), no-store (do not cache at all), must-revalidate (revalidate when stale), immutable (resource will never change), stale-while-revalidate (serve stale while fetching fresh in background). ETag and Last-Modified support conditional requests. Expires (HTTP/1.0 legacy) and Pragma still ship for backward compat but Cache-Control wins on conflict.
What's a healthy cache strategy by resource type?
HTML: short TTL (Cache-Control: public, max-age=300, s-maxage=600, stale-while-revalidate=86400) — content changes often. Versioned JS/CSS (file.abc123.js): long-immutable (Cache-Control: public, max-age=31536000, immutable) — file URL changes when content changes. Unversioned JS/CSS: short TTL with revalidate (max-age=600, must-revalidate). Images (versioned): max-age=31536000, immutable. API JSON: typically no-store or short max-age=60 with private. Static assets at edge: s-maxage=86400+ for CDN benefit.
Why does my cache grade say no caching headers found?
Without Cache-Control, browsers fall back to heuristic caching (typically 10% of (Date - Last-Modified), capped at a few minutes). CDNs may not cache at all without explicit Cache-Control. The result: every request hits origin, TTFB suffers, bandwidth costs balloon. Add at minimum a Cache-Control: public, max-age=N to every cacheable response. The grade above flags missing headers as a critical issue.
ETag or Last-Modified — should I ship both?
Either one enables conditional requests (304 Not Modified responses that save bandwidth). ETag is more precise — it changes when the resource changes regardless of timestamp. Last-Modified is timestamp-based, simpler to generate. Most servers ship both; on conflict, ETag wins per RFC 9110. Modern setup: ETag for dynamic content, Last-Modified for static files. The checker above flags missing both as a missed conditional-request opportunity.
Does this tool save my data?
No. Header parsing happens in your browser. Nothing is sent to any server. Closing the tab clears the data. The Copy Results button puts a plain-text summary on your clipboard.
Cache grade below B?
Our web development engagements ship Cache-Control + ETag + Vary correctness across HTML, JS, CSS, and image asset tiers — typically a 30-50% TTFB improvement on cached requests.
Published .