Check cross-origin isolation before a web demo

Your web demo works on your computer, but a feature fails when you present it, or a browser reports that the page is not cross-origin isolated. That state depends on the page's security headers and the resources it loads, not just on whether your browser supports the feature.

Check the page directly before the demo, then use the Browser Info tool to record the browser version and engine if you need to compare or report results. The tool describes browser capabilities, but the page check below tells you whether isolation is active in that specific tab.

Check the page before your demo

1. Open the Browser Info tool and note the browser version and engine. This gives you useful context if the demo behaves differently on another computer.
2. Open the web demo at the same address and in the same browser profile you plan to use during your presentation. Test the top-level page, not a preview embedded in a different website.
3. Open the browser's developer tools, select the Console, and enter window.crossOriginIsolated. The browser returns true or false.
4. If you get false, open the Network panel, reload the page, and inspect the main document's response headers. Also check requests for workers and cross-origin resources that the demo needs.

Run the check after each deployment or configuration change. A result from a local development server does not prove that the production site, a staging address, or a page inside an iframe has the same isolation state.

What the result means

true: this page is cross-origin isolated

The current page is running in an isolated browsing context. This is the state some web features require, including certain uses of SharedArrayBuffer and more precise timing. It confirms the page's current context, not that every feature in your demo works. Test the feature itself as well.

false: isolation is not active here

The browser can run the page, but this document does not currently meet the isolation requirements. The usual cause is a missing or incorrect response header. A cross-origin script, image, worker, or other resource that has not been made available under the required sharing policy can also prevent the setup from working.

The value differs between a main page and a preview

The check applies to the document selected in the developer tools. An embedded frame can have a different security context from its parent, and a preview service may send different headers from your deployed site. Select the right frame in the developer tools, or open the actual demo address in its own tab and test there.

The console reports an error instead of a value

Make sure you typed window.crossOriginIsolated into the JavaScript console and that the page finished loading. If the developer tools are attached to a browser extension or another context, switch to the demo page's context and try again.

How to fix a false result

1. Serve the demo from a secure context. Use HTTPS for a deployed site. Localhost is generally treated as secure for development, but an ordinary HTTP address on another machine or hostname may not be. Check the address used for the presentation, not only your local test.
2. Set the required response headers. The main document commonly needs Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp. Some deployments can use Cross-Origin-Embedder-Policy: credentialless instead, depending on their resource and browser requirements. Ask whoever manages the web server or hosting configuration to set the headers on the document response.
3. Make cross-origin resources compatible. With the require-corp policy, resources from other origins need to opt in through appropriate CORS or Cross-Origin-Resource-Policy headers. Check the Network panel for blocked requests. A missing script, font, image, or worker can cause the demo to fail even if the main document has the expected headers.
4. Check workers and embedded content. If the demo uses a worker, verify that it loads successfully from the intended address and receives the needed headers. If the demo runs inside another site's iframe, test it as a top-level page too. The embedding page and frame can impose additional restrictions.
5. Reload after changing the server configuration. Reload the page and check window.crossOriginIsolated again. If the result does not change, inspect the response actually received by the browser. A cache, proxy, content delivery network, or service worker may still be serving an older response.
6. Repeat the test in the presentation browser. Update the browser if it is old, then test the deployed address in the same browser profile and network you will use for the demo. A managed device or network can apply policies that are not present on your development computer.

Why the headers matter

Cross-origin isolation is a browser security boundary. The opener policy separates the page from certain windows opened from other origins. The embedder policy requires the page to load outside resources in a way that explicitly allows them. Together, these controls help prevent one site from sharing sensitive process-level information with another.

That is why adding headers can uncover unrelated-looking failures, such as a third-party script or font no longer loading. Do not remove a resource's protections just to make the demo load. Identify which resource is blocked, then configure its server or your page's resource policy so the browser can load it safely.

Before presenting, check the production URL in the browser you will use and keep a note of the result alongside its version and engine.