Guide · browser HTTP cache · 4 Oct 2026
Browser cache partitioning: what it changes
A browser may keep separate HTTP-cache state for the same resource under different top-level sites. That is separate from response policy and from shared-cache behavior.
Short answer
The Fetch Standard models a user-agent HTTP cache partitioned using a network partition key whose first component is the top-level site; a second component is null or implementation-defined. This adds a browser-managed candidate boundary. RFC 9111's method/target-URI key minimum, Vary matching, storage, freshness, and validation still apply.
Do not use partitioning as a privacy policy. It does not make a response fresh, private, or safe to share; does not clear old entries; and does not set a CDN or proxy key.
Separate the three layers
| Layer | Decision | Example evidence |
|---|---|---|
| Browser partition | Which top-level browsing context may select a browser-local HTTP-cache candidate? | Record browser/version, profile, top-level site, frame context, request URL and whether a request happened. |
| HTTP cache rules | May this cache store or reuse the matching representation now? | Inspect method, target URI, Vary, Cache-Control, age/freshness, validators and status. |
| Shared intermediary | What did a CDN, reverse proxy, or corporate proxy store, match, or forward? | Use that provider's own configuration, logs and named-hop status. The browser's internal partition is not its cache key. |
Expected example — not a browser test
Assume one browser profile and the same ordinary third-party GET URL and request variants. A warm repeat under top-level site A may select A's existing partition entry if normal HTTP rules allow it. The same URL under unrelated top-level site B is expected to use a separate ordinary browser partition. Returning to A may make A's earlier entry eligible again; it may be fresh, stale, validated, or evicted. A miss in B does not prove A was evicted, that the origin changed, or that a CDN missed.
These are sourced expectations, not measurements. Browser keys and exceptions vary by engine, version, and configuration. Chrome's older key description is historical; Chrome later documented an additional navigation input and Chromium source describes a selective resource-sharing path. Firefox documents default network partitioning since Firefox 85, with configurable behavior. WebKit documents first-party partitioning of third-party HTTP-cache entries but does not publish a complete tuple in the cited summary.
Choose headers for storage audience
private prevents compliant shared caches from storing the response but permits a private cache to store it. no-store instructs HTTP caches not to store the exchange, but does not recall an older response or guarantee privacy against every system or threat. Use a suitable policy for sensitive data and separately review application storage and every intermediary. Browser partitioning is not a substitute.
When diagnosing different results
- Hold method, exact URL, request headers, and
Varyinputs constant; record the browser version, profile, top-level site, and frame context. - Apply ordinary cache storage, key, freshness, stale, and validation rules to the candidate within that context.
- Check whether there was a network request; exclude history/bfcache and service-worker/application caches.
- Identify the shared hop separately. Missing
Age,Via,Cache-Status, or vendor headers are unknown, not proof of a miss.
See the dated report for the engine comparison, expected context table, sources, and caveats. Related: cache keys and privacy, serving-layer diagnosis, and when stale HTTP content is allowed.