HTTP Cache Analyzer

Server assisted New Website & HTTP Diagnostics

Requests a URL through the Mutqan server, or reads response headers you paste, and explains the caching policy they set under RFC 9111: how long browsers and shared caches may reuse the response, how it is revalidated, which request headers split the cache, and what the CDN status headers say. An optional second request shows whether the edge that answered stored the response between the two.

Privacy: The Mutqan server sends the small, fixed test requests described on this page to the host you name, and nothing is stored. Use it only against systems you are authorised to test.

How do browsers and CDNs decide how long to cache a page?

Each cache reads the response headers: Cache-Control max-age gives the lifetime for every cache, s-maxage or a CDN-specific header overrides it for shared caches, no-store forbids storing and private keeps the copy in the browser only. Once the lifetime runs out, an ETag or Last-Modified lets the cache revalidate with a cheap conditional request instead of downloading the page again. A CDN applies this policy separately in each edge location, which is why its cache status and Age differ between visitors.

Security note: A response that sets a cookie or shows personal data must be private or no-store; if a shared cache stores it, the next visitor can receive someone else's page.

How to use HTTP Cache Analyzer

  1. Enter the URL of a page, file or API response — or paste its response headers into the second field.
  2. Tick "Request twice to watch the edge cache" if you want to see whether the CDN stores the response.
  3. Press Analyze caching and read the Cache policy: the verdict, the browser and shared-cache lifetimes and how revalidation works.
  4. Work through the Findings, compare the CDN headers of the two requests, and adapt the suggested policy on the server or CDN.

HTTP Cache Analyzer features

  • Fetches a URL through the Mutqan server and reads only its response headers, or analyzes headers you paste (a raw response, curl -I output or "Name: value" lines) without sending anything
  • States the caching policy in plain words: whether browsers and shared caches may store the response, for how long each, and how a stale copy is revalidated
  • Explains every Cache-Control directive present — max-age, s-maxage, public, private, no-cache, no-store, must-revalidate, immutable, stale-while-revalidate and the rest
  • Reads ETag and Last-Modified, Expires and Date, Age and Vary, and CDN headers such as CF-Cache-Status, X-Cache, X-Served-By, CDN-Cache-Control and Surrogate-Control
  • Flags policy mistakes: a cookie-setting response that shared caches may store, contradictory directives, invalid dates, Vary on Cookie or User-Agent, a compressed response without Vary: Accept-Encoding, no validator
  • Optionally requests the URL a second time to show whether the edge that answered stored the response between the two requests
  • Suggests a starting policy for the kind of response, to adapt rather than copy blindly

Inputs and outputs

Inputs

  • URL to analyze — any public http:// or https:// address; a bare host name gets https:// added.
  • Or paste response headers — analyzed in the browser and used instead of the URL; a status line is optional (200 is assumed without one).
  • Request twice to watch the edge cache — off by default; makes one more request to the final URL.

Outputs

  • Summary — the verdict, the browser and shared-cache lifetimes, the Age, the validators present and the HTTP status.
  • Cache policy — the verdict in a sentence, browser and shared-cache behaviour, where the lifetime comes from, revalidation, Vary and the URL measured.
  • Cache-Control directives, Findings and CDN and proxy headers — each with its meaning; the findings are downloadable as CSV.
  • Two requests compared and What the second request shows — when the second request was asked for.
  • Suggested starting policy — example headers for this kind of response.

HTTP Cache Analyzer example

A page cached for an hour at the edge but split by cookie

Input:

URL to analyze: https://shop.example.com/ · Request twice to watch the edge cache: on

Output:

Verdict Cacheable · Browser lifetime 5 minutes · Shared-cache lifetime 1 hour · Validators ETag · HTTP status 200
Verdict: Cacheable: browsers may reuse it for 5 minutes and shared caches for 1 hour.
Revalidation: Conditional request with If-None-Match: W/"5f8d-1a2b3c"
Warning (Vary): Vary on Cookie splits the cache into a variant per value, so few requests are served from it.
cf-cache-status MISS → HIT; age — → 2
The edge that answered stored the response: the first request was MISS and the second a HIT.

How to read the HTTP Cache Analyzer results

Cacheable with two lifetimes means browsers and shared caches keep the copy for different times: s-maxage or a CDN-specific header lets a CDN keep a page longer than browsers, which then ask the CDN again.

no-cache does not mean "not cached": the copy is stored and checked before each use, which is cheap with an ETag (a 304 answer has no body). no-store is the directive that forbids storing.

A Problem about cookies or authentication is the one to fix first: a shared cache that stores a response meant for one person can hand it to the next visitor.

The CDN status and Age describe the edge that answered the Mutqan server at that moment. A MISS followed by a HIT means that edge stored the response; other edges fill their caches independently.

When to use HTTP Cache Analyzer

  • Before a launch, check that versioned assets are cached for a long time and HTML pages briefly or with revalidation.
  • Find out why a CDN keeps missing: look for no-store, private, Set-Cookie, Vary on Cookie or a BYPASS or DYNAMIC status.
  • Confirm that pages carrying personal data are private or no-store and never cached by shared caches.
  • Review headers copied from a load test, a browser's developer tools or curl -I by pasting them, without fetching anything.

Troubleshooting

  • The verdict says "Heuristic": the response sets no Cache-Control or Expires, so each cache picks its own lifetime. Set an explicit policy so caching is predictable.
  • The second request is still a MISS: the response may not be cacheable at the edge (cookies, private, a BYPASS rule), or the two requests reached different cache nodes. Run it again, and check the CDN's cache rules.
  • The headers differ from what your browser shows: the Mutqan server sends no cookies and a fixed User-Agent, so a site that varies by login, device or country may answer it differently. Paste the headers from your browser's network panel to analyze those instead.
  • A refusal such as "This address cannot be reached from the Mutqan server": private, reserved and blocked addresses are never requested. Paste the headers for an internal system instead.

Frequently asked questions about HTTP Cache Analyzer

Whose cache does this result describe?

The headers are the ones the site sent to the Mutqan server, which runs on Cloudflare's network. A CDN answers from the node nearest to each client, so a visitor elsewhere may get a different Age or cache status, and a site can vary its headers by country, device or cookie. The policy in Cache-Control is usually the same everywhere; the cache status is a snapshot of one node.

What is the difference between max-age and s-maxage?

max-age is how long any cache, including the browser, may reuse the response without asking the server. s-maxage applies only to shared caches such as CDNs and proxies and overrides max-age there, so a site can keep pages fresh in a CDN for an hour while browsers check every minute.

Does no-cache mean the response is not cached?

No. no-cache lets a cache store the response but requires it to revalidate with the server before every reuse, which is cheap when an ETag or Last-Modified allows a 304 Not Modified answer. no-store is the directive that forbids storing the response at all.

Why does the second request show a HIT and the first a MISS?

The first request found nothing in that edge's cache, so the edge fetched the page from the origin and stored it if the policy allowed; the second request was answered from that stored copy. If both requests miss, the response is either not cacheable at the edge or the two requests reached different cache nodes.

Technical notes

RFC 9111 defines HTTP caching: Cache-Control directives decide whether a response may be stored and for how long (max-age for every cache, s-maxage for shared ones, Expires minus Date when max-age is absent), Age is a cache's estimate of how long ago the origin generated or revalidated the copy (RFC 9111 §5.1), and ETag or Last-Modified let a stale copy be revalidated with a conditional request answered 304 Not Modified. immutable comes from RFC 8246 and stale-while-revalidate and stale-if-error from RFC 5861.

In URL mode one GET is sent through POST /api/v1/internet/http/fetch with a fixed header profile; redirects are followed and the final response is analyzed, with the body capped at one byte because only the headers matter. The second request goes to the final URL without following redirects.

CDN status headers are vendor conventions, not standards: CF-Cache-Status is Cloudflare's (HIT, MISS, EXPIRED, BYPASS, DYNAMIC and others), X-Cache is used by several CDNs and proxies, and CDN-Cache-Control or Surrogate-Control target the CDN layer only.

Limitations and methodology

The URL is requested from the Mutqan server on Cloudflare's network; the CDN status and Age describe the edge that answered that request, which may differ from the node nearest to a visitor.

The analysis reads response headers only. It cannot see browser memory or service-worker caches, CDN rules that override the headers, or how long a cache really keeps a copy before evicting it.

Requests carry no cookies or credentials, so caching that depends on a logged-in session is not observed.

Security and privacy

Pasted headers never leave your browser. In URL mode the Mutqan server receives the URL, requests it once (twice when asked) with fixed headers and none of your cookies, and stores nothing; only the response headers are returned.

References

  • RFC 9111: HTTP CachingIETF · 2022How Cache-Control, Expires, ETag and validators decide whether a response may be stored and reused.
  • HTTP caching — MDNMDN Web Docs (Mozilla)Private vs. shared caches, freshness, validation with ETag / Last-Modified and the common Cache-Control patterns.
  • Prevent unnecessary network requests with the HTTP Cacheweb.dev (Google)A practical guide to Cache-Control: long max-age with versioned URLs, no-cache with ETag for HTML, private for personal data, and how browsers revalidate.