CDN Cache Checker

Find out whether a page or image is being served from a CDN edge cache or fetched from your origin every time — and if it isn't cached, exactly which header is stopping it.

Requests the URL twice — a first-request MISS is normal and proves nothing on its own. Works on pages, images, CSS, JS and any other public URL.

Paste a URL to see whether it is served from cache, and what its caching headers actually say.

Not checked

Run a check to see the cache status.

CDN / Cache — identified from response headers

Cacheability — how well the headers are set up

Edge TTL — s-maxage, or max-age if unset

Age — time already spent in cache

🌐 Request Journey

Where this URL was actually served from, and whether your origin was contacted at all.

Browser

A returning visitor checks here first. This check runs from our server, which has no cached copy of your site — so this layer took no part in what was measured below.

—

request

CDN Edge

If an edge holds a fresh copy it answers here and your origin is never touched.

—

origin fetch

Origin Server

Your own server. Every request that reaches here costs you compute and the visitor a full round trip.

—

🔁 The Two Requests

Same URL, moments apart. The pair is what distinguishes a cold cache from a broken one.

Request Cache status Raw header Age Time

🔎 Findings

⚙️ Cache Directives

Cache-Control

—

max-age

—

s-maxage

—

ETag

—

Last-Modified

—

Expires

—

Vary

—

Set-Cookie

—

📋 Request Details

Final URL

—

Host

—

Content type

—

Size

—

Compression

—

Protocol

—

Redirects followed

—

Edge location

—

Detected via

—

Checked at

—

💻 Browser Cache Policy

What this response permits a visitor's own browser to do. Read from the directives — a server cannot observe another person's browser cache, so nothing here is a claim about one.

🧠 The Four Cache Layers

Keeping them separate is what makes a cache result trustworthy.

Browser memory

Reused within a single tab session. Never observable from outside that browser.

Browser disk

Survives a restart. Governed entirely by the headers shown on this page.

CDN edge

Shared between all visitors near that POP. This is what HIT and MISS describe.

Origin / app

Redis, output caching, a reverse proxy. Invisible from outside unless a header says so.

🌍 Cache at the Edge, Worldwide

A cache hit is per edge location — being cached in one region says nothing about another. These are real probes in each country.

Location Cache status Edge / POP Age Time

Worldwide check starts once the main result is in.

🧾 Cache Headers, Explained

Only the headers that affect caching, with what each one is doing on this response.

Header Value What it does here

📦 All Response Headers

A first-request MISS is completely normal — the object simply was not at that edge yet, and the request itself puts it there. That is why this tool always asks twice: MISS then HIT means caching is working, while MISS then MISS means something is genuinely preventing it. Checking once and reporting the MISS, as most cache checkers do, cannot tell those two apart.

HOW IT WORKS

Two Requests, Because One Proves Nothing

Any object that is not currently at the edge returns a MISS on its first request — that is what a cache miss means. A checker that fetches once and shows you that MISS is reporting the state it just created, which is why so many people conclude their CDN is broken when it is working perfectly. This tool requests the same URL twice, a fraction of a second apart, and reads the pair: MISS then HIT is a healthy cache that had simply gone cold, HIT then HIT is already warm, and MISS then MISS is the genuine failure worth investigating. A rising Age header between the two corroborates it, since only a shared cache sets that header and only a stored object's age grows. The provider is identified from its own fingerprints — cf-cache-status and cf-ray for Cloudflare, x-amz-cf-pop for CloudFront, x-served-by for Fastly, and the RFC 9211 Cache-Status header for anything modern — and when nothing is cached, the findings name the specific header responsible rather than leaving you to guess.

What else can you check?

These tools all work on the same connection and address data — pick whichever question you actually have.

Want to see the full path to a site? DNS, redirects, every hop, the CDN, TLS and the origin server. Want to know your public IP? See your IPv4 and IPv6 addresses, location, ISP and ASN. Want to check your tower & route? Live ping, speed, DNS, traceroute and a map of nearby points. Want to ping from around the world? Real latency from real probes across 12 countries, live on a map. Want to locate any IP address? City, region, country and coordinates for any public IP. Want to know if an IP is risky? Proxy, VPN, Tor, hosting and abuse-report indicators. Want to know if you're blacklisted? Check an address against major spam and abuse DNSBLs. Want to know who owns an IP? Network owner, ASN, CIDR range and abuse contact. Want to explore an AS number? Announced prefixes, BGP neighbours and registry details. Want to test your connection speed? Measure real download, upload, ping and jitter. Want to see what changed? Word-level diff between two blocks of text or code. Want to know if a DNS change is live yet? Compare answers from five independent public resolvers. Want to verify a domain's nameservers? Direct authoritative checks, glue records and SOA serials. Want to check a domain's DNSSEC setup? DNSKEY, DS records, signature expiry and real validation. Want to see the hop-by-hop path to a server? A real traceroute from a genuine probe anywhere in the world. Want to know if a server port is open? A real TCP connection attempt - open, closed or filtered. Want to measure latency to a server? Real connect timing - min/avg/max, jitter and connection loss. Want a clean URL slug from a title? Real transliteration, stop words and batch mode. Want to find and replace across a document? Regex, capture groups and a live preview before you commit. Want to find the invisible character? Code points, escapes, bytes and hidden-character detection. Want to escape text for HTML? Minimal, named or numeric entities, attribute-safe. Want to strip emoji cleanly? Whole clusters - no half-flags or stray modifiers left. Want to spot repeated words? Frequency, density and accidental doubles like "the the". Want to see what a site knows about you? Storage, cookies, tokens and what your browser actually cached. Want to run that check on any site? One-click bookmarklet reads storage and tokens where they live. Want to know who your site talks to? Renders the page and names every outside company it contacts.

COMMON QUESTIONS

CDN Cache Checker FAQ

Why does it say MISS the first time and HIT the second?

That is a healthy cache. The object was not stored at that edge yet, so the first request had to fetch it from your origin — and in doing so, put it in the cache. The second request found it there. Nothing is wrong; the first visitor to any cold object always pays this cost.

Both requests say MISS. What now?

Check the findings panel — it names the specific cause. The usual culprits are a Set-Cookie header on a static asset (most CDNs refuse to cache those), Cache-Control: private or no-store, a Vary header that fragments the cache, or simply no max-age/s-maxage at all, which leaves the CDN nothing to act on.

Why check from other countries too?

Because a CDN cache is per edge location, not global. An object can be hot in London and cold in São Paulo at the same moment, and each POP fills independently on its own first request. A single-location check tells you about one edge out of hundreds.

Does this work for images and other assets?

Yes — any public URL. Images, CSS, JavaScript and fonts are usually the most interesting things to check, because they are the ones that should be cached aggressively and the ones where a stray cookie or missing max-age quietly costs you every time.

What is a good cacheability score?

It depends entirely on what the URL is. A fingerprinted asset should be near 100 with a long s-maxage and immutable. A personalised HTML page scoring very low is correct behaviour, not a fault. Treat the score as a description, not a target.

Does checking warm my cache?

Slightly, yes — and unavoidably, since the only way to observe cache behaviour is to make real requests. The two requests here are ordinary GETs with no cache-busting and no no-cache header, so they behave exactly like a visitor's would.