Dated research report · browser HTTP cache · 4 Oct 2026

Browser HTTP-cache partitioning: context is not policy

A top-level site can define an additional browser-local cache partition. It does not replace HTTP cache matching or freshness rules, and it does not configure a CDN or proxy.

Source review retrieved 4 Oct 2026 at 09:20 UTC · source run run:15874c5d-15d3-4e59-a57c-1ce0c913276d · documentation-only; no browser, server, endpoint, intermediary, or cache was tested.

Short answer

In the Fetch Standard's model, a user agent associates an HTTP cache with a network partition key whose first component is the top-level site; another component is left null or implementation-defined. This gives browsers a context boundary in addition to ordinary HTTP cache matching. A matching response still must satisfy storage, Vary, freshness, stale-use, and validation rules. The browser's partition does not set the key or retention policy of an intermediary.

A and B may each hit their own matching reusable local entry; the shared intermediary is reached only when the current context has no otherwise reusable browser entry. Partitioning does not force every request to the network. HTTP rules still decide reuse, and the intermediary has separate state and controls.

Three mechanisms, three questions

Question	Mechanism	What it tells you
Which stored response is a candidate?	HTTP cache key, plus any cache-specific additional key material. A user agent can use a site/context partition.	Same URL may be a separate browser-local candidate under another top-level site. A CDN or proxy can use its own key.
Does this request match the stored variant?	Method and target URI, plus `Vary`-nominated request fields and other matching requirements.	`Vary: Accept-Language` distinguishes nominated language variants. It does not specify a browser's hidden partition key.
May a cache store or reuse it now?	`Cache-Control`, freshness, stale rules, and conditional validation.	A candidate can still be prohibited from storage, stale, or required to validate. Partitioning does not make it fresh or safe to share.

RFC 9111 defines the minimum cache key as request method plus target URI and permits caches to add key material. It separately specifies Vary matching, storage, freshness, and validation. The Fetch Standard defines the user-agent partition model; it does not replace these HTTP rules. RFC 9111 §2 · RFC 9111 §4.1 · Fetch Standard §§2.7–2.8

Partitioning is not a privacy directive

Use response policy for the storage audience. private prohibits a compliant shared cache from storing the response but allows a private cache to store it if other rules permit. no-store instructs HTTP caches not to store the exchange; it does not remove an older copy or provide a universal privacy guarantee against compromised caches, eavesdropping, application storage, history, backups, or other systems. A browser partition does not configure a CDN, reverse proxy, corporate proxy, or origin. If sensitive bytes must not be retained by compliant HTTP caches, use a suitable policy such as no-store and separately review every other storage path. RFC 9111 §5.2.2.5 · RFC 9111 §7.3

What browser documentation supports

These are vendor/engine documentation claims, not a single portable key formula. Capture the exact browser and version when diagnosing a client.

Engine	Documented claim	Scope limit
Chromium / Chrome	The 2020 Chrome article describes the Chrome 86-era rollout and its then-key: top-level schemeful site and current-frame schemeful site, in addition to resource URL. Chrome 136 later documented an `is-cross-site-main-frame-navigation` key input. The current Chromium source tree also has a selective single-keyed path for a curated set of extremely pervasive resources.	The 2020 tuple is historical, not a current cross-build promise. A 2025 intent-to-ship targeted a later milestone for the selective path; source and intent do not establish which current channel/build has it enabled or whether a resource qualifies. Chrome's 2020 article · Chrome 136 notes · Chromium source README · intent to ship
Firefox	Mozilla documents network partitioning, including the HTTP Cache, as enabled by default since Firefox 85 and scoped by top-level site. Its broader State Partitioning rollout was default from Firefox 103.	Mozilla documents a preference that can disable network partitioning. This describes Firefox behavior and configuration, not a shared cross-browser key contract. MDN: State Partitioning
WebKit / Safari	WebKit's Tracking Prevention documentation says third-party HTTP-cache entries are partitioned per first-party website.	The cited summary does not publish a complete HTTP-cache key tuple. Do not substitute cookie, Cache API, or service-worker partition details; a WebKit engine statement does not establish every product/version/settings combination. WebKit: Tracking Prevention · WebKit: ITP announcement

The Fetch Standard gives these engines a common model: top-level site is the first network-partition-key component, while a second component is null or implementation-defined. It does not require identical engine keys or cross-frame reuse. Fetch Standard §2.7

Expected context comparison — not tested

The following is an illustration based on the cited standards and engine documentation, not a measurement. Assume one browser profile; the same ordinary third-party GET URL, request headers, and Vary values; a cacheable response; and no resource-specific browser exception.

Context	Expected browser-local result	Do not infer
Repeat under top-level site A	An existing A-partition entry may be selected if matching, storage, and freshness/validation requirements pass.	A local hit does not mean the response is current without applying freshness and validation rules.
Same URL under unrelated top-level site B	Expected to use B's ordinary partition rather than A's entry; B may request and store its own copy.	A B-side miss does not prove eviction of A's entry, a changed origin response, or a CDN miss.
Return to A	A's prior entry may again be a candidate: fresh, stale and validated, or already evicted.	Partitioning itself does not expire, refresh, or delete either entry.

The expected outcomes remain version- and configuration-dependent. The Chrome selective-resource path is one reason not to say every cross-site resource must miss. A different browser profile or a shared intermediary has separate state and needs separate evidence.

Diagnostic checklist

Record browser/version, profile, main-frame versus subresource, top-level site, immediate frame site, method, exact URL, and redirect hops. A site is not always the same as a full origin.
Keep request headers named by Vary and the resource URL fixed. Use harmless response markers; redact cookies, authorization, and user data.
Capture Cache-Control, Date, Age, Expires, Vary, validators, request conditionals, and 200/304 status. Apply the ordinary freshness/validation rules within each candidate partition.
Check whether a network request occurred. Exclude history/bfcache and service-worker or application-managed Cache Storage before labeling a response an HTTP-cache hit.
Identify a CDN/proxy separately with its documented status/logs and configuration. Age, Via, Cache-Status, or vendor fields are scoped evidence; missing fields are unknown. The browser partition does not identify which intermediary answered.

For the broader key/privacy model, see Cache-key & privacy mismatch. For multi-hop evidence, see Serving-layer diagnosis and the stale HTTP report.

Evidence and limits

Normative HTTP: RFC 9111 defines cache-key minimum/additional material, Vary, storage, freshness, stale reuse, validation, and the distinct meanings of private and no-store.
Platform standard: Fetch specifies a user-agent HTTP-cache partition using a network partition key with top-level site as its first component and an intentionally open second component.
Implementation evidence: Chrome/Chromium, Mozilla, and WebKit sources describe their own dates, settings, and exceptions. They do not establish one identical current tuple for every browser.
Expected, not observed: Site A/B examples above are sourced expectations. No browser profile, request, response, origin, intermediary, CDN, cache, privacy exposure, or stale result was tested in this run.
Unknown: the complete key for a specific current browser build/request, user settings, any qualifying Chromium resource exception, and the key/storage policy of a particular shared intermediary.

Sources and retrieval time

All online sources below were retrieved 4 Oct 2026 at 09:20 UTC. RFC and WHATWG Fetch are standards. Engine/vendor documentation supports only the stated implementation and scope.

RFC 9111 — HTTP Caching, §§2, 3, 4–4.3, 4.1, 5.2.2.4–5.2.2.7, 6, 7.2–7.3.
WHATWG Fetch Standard, §§2.7–2.8: network partition keys and HTTP cache partitions.
Chrome for Developers: Gaining security and privacy by partitioning the cache, Chrome 86-era historical explanation.
Chrome 136 release notes, version-specific navigation key input.
Chromium source: pervasive-resource cache sharing README and intent to ship, selective path and rollout caveats.
MDN: State Partitioning, Mozilla-maintained Firefox network/state partition documentation.
WebKit: Tracking Prevention and Intelligent Tracking Prevention, engine-level HTTP-cache statements.