Chromium‎ > ‎Chromium Security‎ > ‎

Site Isolation


Site Isolation is an optional security feature in Chrome that offers additional protection against some types of security bugs.  It makes it harder for untrusted websites to access or steal information from your accounts on other websites.

Websites typically cannot access each other's data inside the browser, thanks to code that enforces the Same Origin Policy.  Occasionally, security bugs are found in this code and malicious websites may try to bypass these rules to attack other websites.  The Chrome team aims to fix such bugs as quickly as possible.

Site Isolation offers a second line of defense to make such attacks less likely to succeed.  It ensures that pages from different websites are always put into different processes, each running in a sandbox that limits what the process is allowed to do.  It also blocks the process from receiving certain types of sensitive data from other sites.  As a result, a malicious website will find it more difficult to steal data from other sites, even if it can break some of the rules in its own process.

For more technical information about the protections offered by Site Isolation and how they are built, please see the project's design document.

Current Status

In Chrome 63 and later, turning on Site Isolation offers additional protection against a certain type of web browser security bug, called universal cross-site scripting (UXSS).  Security bugs of this form would normally let an attacker bypass the Same Origin Policy, though they don't give the attacker complete control over the process.  Site Isolation can help protect sites even when these UXSS bugs occur.

In addition to UXSS bugs, Site Isolation can also help to mitigate attacks that are able to read otherwise inaccessible data within a process, such as speculative side-channel attack techniques like Spectre/Meltdown.  Site Isolation reduces the amount of valuable cross-site information in a web page's process, and thus helps limit what an attacker could access.

This protection is made possible by the following changes in Chrome's behavior:
  • Cross-site pages are always put into a different process, whether the navigation is in the current tab, a new tab, or an iframe (i.e., one web page embedded inside another).
  • Cross-site data (specifically HTML, XML, and JSON files) is not delivered to a web page's process unless the server says it should be allowed (using CORS).
There is additional work underway to let Site Isolation offer protection against even more severe security bugs, where a malicious web page gains complete control over its process (also known as "arbitrary code execution").  These protections are not yet fully in place.

We have begun trials to evaluate when to enable Site Isolation more broadly.

Known Issues

Support for Site Isolation is still in progress, and there are a set of known issues when turning it on in its current form.  The issues described below reflect Chrome 65, and they mostly affect sites that are isolated or that contain subframes from sites that are isolated.  This may include all sites or just certain sites, as explained in "How to Configure" below.  Some users or enterprises may find the security benefits worth the current tradeoff.

For users:
  • Higher overall memory use in Chrome (about 10-12% in Chrome 65 when isolating all sites with many tabs open).

  • When printing a page, cross-site iframes appear blank.
    To print the complete web page content, save the page locally, then open and print the saved file.  (This is fixed in Chrome 66.)

  • In some cases, scrolling in cross-site iframes may not work properly.  (Many of these are fixed in Chrome 66.)

  • In some cases, iframes may have the wrong size or are clipped incorrectly.  (This is fixed in Chrome 66.)
For web developers:
  • Some features in Chrome's Developer Tools have issues with cross-site iframes, such as inspecting elements.  (This is fixed in Chrome 66.)

  • Website testing frameworks using ChromeDriver should update to version 2.37 to support cross-site iframes.
We are working to resolve these issues so that Site Isolation can be enabled more broadly.

How to Configure

There are two ways to enable Site Isolation: isolating all sites, or isolating a list of certain sites.

1) Isolating All Sites

This mode is easier to enable and ensures that all websites are put into dedicated processes that are not shared with other sites.  It can be enabled in any of the following ways:

2) Isolating Certain Sites

This mode allows you to provide a list of specific origins that will be given dedicated processes, rather than isolating all sites.  The main advantage of this mode is that it typically uses less memory than isolating all sites.  If using this approach, we recommend including sites that need extra protection on the list, such as any site that you log into.  (Note that subdomains are automatically included, so listing will also protect  This mode can be enabled in either of the following ways:
  • Use command line flags to start Chrome with --isolate-origins followed by a comma-separated list of origins to isolate.  For example:
    Be careful not to include effective top-level domains (e.g., or; see the full list at, which will be ignored.

  • Or, use an Enterprise Policy to enable IsolateOrigins within your organization.
Both "Isolating All Sites" and "Isolating Certain Sites" work on Chrome for Windows, Mac, Linux, and ChromeOS.  "Isolating All Sites" also works on Chrome for Android, but only via chrome://flags#enable-site-per-process.  Note that changes to chrome://flags and the command line only affect the current device, and are not synced to your other instances of Chrome.

Diagnosing Issues

If you encounter problems when Site Isolation is enabled, you can try turning it off by undoing the steps above, to see if the problem goes away.

You can also try opting out of field trials of Site Isolation to diagnose bugs, by visiting chrome://flags#site-isolation-trial-opt-out, choosing "Opt-out (not recommended)," and restarting.

Note that some issues might be resolved by turning off just the data blocking feature, which leaves some of the protections from process isolation in place.  To try this, start Chrome with the following command line flag: 

Note that none of these options can be used to disable Site Isolation if it has been enabled by enterprise policy.

We encourage you to file bugs if you do encounter problems when using Site Isolation, describing the problem and mentioning that you are using Site Isolation.


If you would like to test that Site Isolation has been successfully turned on, you can follow the steps below:
  1. Navigate to a website that has cross-site subframes.  For example: 
  2. Open Chrome's Task Manager: Chrome Menu -> More tools -> Task manager (Shift+Esc).
  3. Verify that the main page and the subframe are listed in separate rows associated with different processes.  For example:
    • Tab: - Process ID = 1234
    • Subframe: - Process ID = 5678
If you see the subframe process in Chrome's Task Manager, then Site Isolation is correctly enabled.  These steps work when using the "Isolating all sites" approach above (e.g., --site-per-process).  They also work when using the "Isolating certain sites" approach above (e.g., --isolate-origins), as long as the list of origins provided includes either or

Recommendations for Web Developers

Site Isolation can help protect sensitive data on your website, but only if Chrome can distinguish it from other resources which any site is allowed to request (e.g., images, scripts, etc.).  Chrome currently tries to identify URLs that contain HTML, XML, and JSON files, based on MIME type and other HTTP headers.  The guidelines below can help you ensure that sensitive information on your website will be protected by Site Isolation.

Chrome should be able to effectively protect URLs that have both a protected MIME type and a nosniff response header. More specifically, the HTTP response for the URL should be labeled with one of these MIME types in the "Content-Type" HTTP response header:
  • text/html
  • text/xml
  • application/xml
  • application/rss+xml
  • application/json
  • text/json
  • text/x-json
  • text/plain
The HTTP response should also have a "X-Content-Type-Options: nosniff" HTTP response header, which ensures that the protection will not depend on what the contents of the file look like.

Note that we recommend not supporting multipart range requests for sensitive data, because this changes the MIME type to multipart/byteranges and makes it harder for Chrome to protect.  Typical range requests are not a problem and are treated similarly to the nosniff case.

In addition to the recommended cases above, Chrome will also do its best to protect responses labeled with any of the MIME types above and without a "nosniff" header, but this has limitations. Many JavaScript files on the web are unfortunately labeled using some of these MIME types, and if Chrome blocked access to them, existing websites would break. Thus, when the "nosniff" header is not present, Chrome first looks at the start of the file to try to confirm whether it is HTML, XML, or JSON, before deciding to protect it.  If it cannot confirm this, it allows the response to be received by the cross-site page's process. This is a best-effort approach which adds some limited protection while preserving compatibility with existing sites.  We recommend that web developers include the "nosniff" header to avoid relying on this approach.

For more technical details on these protections, see the Cross-Origin Read Blocking (CORB) Explainer.