Document Isolation Policy #1332

Document-Isolation-Policy (DIP) is an HTTP response header that lets one document opt into cross-origin isolation by itself, without its embedder or its embedded content having to cooperate. It leans on out-of-process iframes for the isolation guarantee instead of the COOP + COEP header pair.

The practical difference: with COOP + COEP, every document in the frame chain has to agree, and the top-level document gives up cross-origin popups and unrestricted third-party embeds to get there. With DIP, a document that needs SharedArrayBuffer or WASM threads turns them on for itself, and the pages around it are unaffected.

In scope: the Document-Isolation-Policy header, its isolate-and-require-corp and isolate-and-credentialless values, the resulting crossOriginIsolated state, inheritance into dedicated and shared workers, and the report-only variant. The isolate-agent-cluster value and service worker behaviour are open questions for the investigation rather than assumed in scope (see the roadmap).

Explainer: https://github.com/WICG/document-isolation-policy

Spec draft: https://wicg.github.io/document-isolation-policy/

TAG review: w3ctag/design-reviews#995

Tests: https://github.com/web-platform-tests/wpt/tree/master/html/document-isolation-policy (38 tests, all still named .tentative.)

The COOP + COEP model has been available since late 2021 and is still painful enough that real products route around it. Sites are not asking for a new capability, they already have SharedArrayBuffer. They are asking to stop choosing between isolation and embedding. Two named cases, both already on the public standards position threads:

WordPress. Client-side media processing shipped in WordPress 7.1 on 2026-08-19. Release: https://wordpress.org/news/2026/08/mary-lou/ and dev note: https://make.wordpress.org/core/2026/07/22/client-side-media-processing-in-wordpress-7-1/

It uses wasm-vips to convert uploads to smaller images in the browser before upload, which both widens format support beyond what a typical PHP host offers and provides new capabilities hosts do not offer. That needs SharedArrayBuffer. But the post editor renders content in an iframe, some hosts render the whole admin panel in an iframe, and WordPress Playground renders an entire ephemeral site in an iframe. The feature was first built on COOP/COEP, hit exactly the frame-chain problem, and moved to DIP: WordPress/gutenberg#75991

WordPress now sends Document-Isolation-Policy: isolate-and-credentialless on block editor screens for Chromium 137+. Everywhere else the feature is unavailable, so Firefox and Safari users fall back to the server-side path. This is a released feature in the most widely deployed CMS on the web, with the capability already varying by browser.

Playground went as far as rewriting COOP/COEP into DIP to make it work: WordPress/wordpress-playground#3028

The mixed case is the one COEP cannot express at all: an isolated editor that still embeds a YouTube video. Details from @adamziel: mozilla/standards-positions#1074 (comment)

HDR photos are a second WordPress motivation, since gain map transcoding also runs through the WASM pipeline: WebKit/standards-positions#399 (comment)

Zoom. Zoom Meetings on web uses COOP/COEP to get SharedArrayBuffer for audio and video processing. Their other products (Docs, Whiteboard) deliberately do not, because it would break embedding YouTube or Asana. That means Zoom cannot offer Meetings inside its own collaboration suite. The Zoom Web SDKs are the mirror image: third-party developers embedding Zoom alongside other iframes in education, healthcare, and finance products. Full comment from @tommygaessler: WebKit/standards-positions#399 (comment)

Related interop demand: #1226 proposed allow="cross-origin-isolated" on iframes for Interop 2026, a narrower attempt at the same underlying problem. It arrived after the window closed and was not carried forward.

Standards positions.

• Mozilla: positive, resolved 2026-08-10. Document-Isolation-Policy mozilla/standards-positions#1074
• WebKit: no position yet, open since September 2024. Document-Isolation-Policy WebKit/standards-positions#399

The WebKit thread still carries concerns: portability and concerns: device independence labels. The device independence concern was raised by @annevk in April 2025: Chrome's initial launch plan was desktop only, which would have made SharedArrayBuffer availability depend on the device. Chrome revised the plan in response and shipped to all Android devices, including those under 2GB of RAM: WebKit/standards-positions#399 (comment). Mozilla read that as resolving the concern when settling their own position: mozilla/standards-positions#1074 (comment). A request for an update on the WebKit thread on 2026-09-01 has not had a reply yet.

Worth flagging: https://chromestatus.com/feature/5141940204208128 records the Safari view as "Negative", with a note describing the since-revised Android plan. That does not match the state of the WebKit thread and is the first thing most people check.

Current state.

• Chrome and Edge: shipped in 137 on desktop and 146 on Android, after an origin trial through 136.
• Firefox: not implemented. Implementation bug filed 2026-08-13: https://bugzilla.mozilla.org/show_bug.cgi?id=2063367
• Safari: not implemented, no WebKit Bugzilla entry yet.
• WPT: 38 tests, all .tentative.. Chrome and Edge pass 189 of 190 subtests on the current aligned run. Firefox nightly passes 123 of 190, but those are the subtests whose expected result does not depend on the header being honoured (credentials-omitted fetches, the missing-HTTPS case, and similar); the main crossOriginIsolated case fails. Safari runs report harness errors rather than results. https://wpt.fyi/results/html/document-isolation-policy
• No web-features id exists for DIP.
• The WICG spec repo has had no commits since April 2025.

DIP is not proposed as a Focus Area because two of the essential criteria are not met: the spec is a WICG Community Group draft rather than a WHATWG or W3C Recommendation Track document, and all 38 tests are still tentative. The Investigation Effort form exists for exactly that shape. Steps, roughly in order:

1. Move the spec to a recognised venue. DIP changes agent cluster keying and document loading, so the HTML Standard is the natural home. With a positive Mozilla position on record, opening a whatwg/html issue to gauge appetite for upstreaming is the first concrete step. This is standards work and belongs in WHATWG, not in Interop; the investigation would track it, not do it.

2. Resolve the remaining WebKit questions. The device independence concern has an answer on the thread that has not been responded to since April 2025. Getting a position recorded either way, and capturing any portability concerns as spec issues, unblocks everything downstream.

3. Get the tests out of tentative. The 38 existing tests are a real starting point, not a greenfield. Once the spec has a stable home, they can be renamed and reviewed against it. Gaps to check while doing that:

   • worker inheritance, including the shared worker cases Chromium still fails
   • reporting under Report-Only: Reporting behavior between normal vs. Report-Only WICG/document-isolation-policy#6
   • interaction with pages already isolated via COOP/COEP
   • agent cluster keying between same-origin documents with and without DIP (the partial-deployment behaviour described in the rationale)
   • the meta tag question: Document-Isolation-Policy Header via meta tag WICG/document-isolation-policy#3

4. File the WebKit implementation bug. Gecko has one; WebKit's tracker has no entry for DIP today, so there is nowhere for developers to register interest or for the work to be tracked.

5. Register a web-features id. This lets future proposals and dashboards pick up standards positions and BCD data automatically.

6. Settle isolate-agent-cluster. What's "isolate-agent-cluster"? WICG/document-isolation-policy#5 is an open question about a value that is not clearly defined in the explainer. Either specify it or drop it from scope.

One question for the Interop team: is upstreaming to WHATWG a prerequisite for this investigation, or something the investigation could help drive? The proposal guide is clear that Interop is not a venue for standards work, and the intent here is not to do spec work under an Interop banner. But sequencing matters for whether this is a 2027 item or a 2028 one.