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 documents 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 "documents" (specifically HTML, XML, and JSON files) are 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.

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 current known issues described below affect the sites that are isolated, which 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 memory use (about 10-20% in Chrome 63 when isolating all sites with many tabs open).
    This overhead can be greatly reduced by only isolating certain sites, as noted below, and drops to about 10% in the heaviest cases in Chrome 64.

  • 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, clicking or scrolling on cross-site iframes may not work properly. 
    For example, this can happen when there is a partly transparent overlay above an iframe.  (This is fixed in Chrome 65.)

  • When using the "Isolating all sites" approach below, Gmail may not load properly if started from the Gmail icon on chrome://apps.
    To work around this, visit rather than using the Gmail icon on chrome://apps.  (This is fixed in Chrome 64.)

  • Gmail Offline, Calendar Offline, and some other hosted apps may not work properly.  (This is fixed in Chrome 64.)
For web developers:
  • Chrome's Developer Tools do not yet fully support cross-site iframes.
    For example:
    • Network requests from cross-site iframes are not displayed in DevTools.  (This is fixed in Chrome 64.)
    • Touch emulation for cross-site iframes is not supported.  (This is fixed in Chrome 65.)
    • Cookies are not displayed for cross-site subresource requests. (This is fixed in Chrome 65.)

  • The window.performance API is not yet supported in cross-site iframes.  (This is fixed in Chrome 65.)

  • Website testing frameworks such as ChromeDriver don't yet support cross-site iframes.  (This is fixed in Chrome 65 and ChromeDriver 2.36.)
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 to 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.


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.

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

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:
    • Tabs: - 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 (i.e., --site-per-process).  They also work when using the "Isolating certain sites" approach above (i.e., --isolate-origins), as long as the list of origins provided includes either or

Recommendations for Web Developers

Site Isolation can help protect sensitive documents on your website, but only if Chrome can distinguish them 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 directive. 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 documents, because this changes the MIME type to multipart/byteranges and makes it harder for Chrome to protect.

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.