Ie Edge Chromium

What is IE mode? IE mode on Microsoft Edge makes it easy to use all of the sites your organization needs in a single browser. It uses the integrated Chromium engine for modern sites, and it uses the Trident MSHTML engine from Internet Explorer 11 (IE11) for legacy sites. Using CanIUse, the most universal feature which is unsupported on old Edge (which used the EdgeHtml engine) but supported in Edge Chromium and everywhere else (except IE), is the reversed attribute on an OL list.This attribute has the advantage of having been supported for ages in everything else. (This is the only one I can find which covers all other browsers including Opera Mini; if that's. Alongside all the features and improvements in the roadmap for the new version of Microsoft Edge based on the Chromium engine, Microsoft includes a compatibility mode using the Internet Explorer rendering engine to load old websites.

Browsers As Decision Makers

As a part of every page load, browsers have to make dozens, hundreds, or even thousands of decisions — should a particular API be available? Should a resource load be permitted? Should script be allowed to run? Should video be allowed to start playing automatically? Should cookies or credentials be sent on network requests? The list is long.

In many cases, decisions are governed by two inputs: a user setting, and the URL of the page for which the decision is being made.

In the old Internet Explorer web platform, each of these decisions was called an URLAction, and the ProcessUrlAction(url, action,…) API allowed the browser or another web client to query its security manager for guidance on how to behave.

To simplify the configuration for the user or their administrator, the legacy platform classified sites into five1 different Security Zones:

  • Local Machine
  • Local Intranet
  • Trusted
  • Internet
  • Restricted

Users could use the Internet Control Panel to assign specific sites to Zones and to configure the permission results for each zone. When making a decision, the browser would first map the execution context (site) to a Zone, then consult the setting for that URLAction for that Zone to decide what to do.

Reasonable defaults like “Automatically satisfy authentication challenges from my Intranet” meant that most users never needed to change any settings away from their defaults.

In corporate or other managed environments, administrators can use Group Policy to assign specific sites to Zones (via “Site to Zone Assignment List” policy) and specify the settings for URLActions on a per-zone basis. This allowed Microsoft IT, for instance, to configure the browser with rules like “Treat as a part of my Intranet and allow popups and file downloads without warning messages.

Beyond manual administrative or user assignment of sites to Zones, the platform used additional heuristics that could assign sites to the Local Intranet Zone. In particular, the browser would assign dotless hostnames (e.g. https://payroll) to the Intranet Zone, and if a Proxy Configuration script was used, any sites configured to bypass the proxy would be mapped to the Intranet Zone.

Applications hosting Web Browser Controls, by default, inherit the Windows Zone configuration settings, meaning that changes made for Internet Explorer are inherited by other applications. In relatively rare cases, the host application might supply its own Security Manager and override URL Policy decisions for embedded Web Browser Control instances.

The Trouble with Zones

While powerful and convenient, Zones are simultaneously problematic bug farms:

  • Users might find that their mission critical corporate sites stopped working if their computer’s Group Policy configuration was outdated.
  • Users might manually set configuration options to unsafe values without realizing it.
  • Attempts to automatically provide isolation of cookies and other data by Zone led to unexpected behavior, especially for federated authentication scenarios.

Zone-mapping heuristics are extra problematic

  • A Web Developer working on a site locally might find that it worked fine (Intranet Zone), but failed spectacularly for their users when deployed to production (Internet Zone).
  • Users were often completely flummoxed to find that the same page on a single server behaved very differently depending on how they referred to it — e.g. http://localhost/ (Intranet Zone) vs. (Internet Zone).

The fact that proxy configuration scripts can push sites into the Intranet zone proves especially challenging, because:

  • A synchronous API call might need to know what Zone a caller is in, but determining that could, in the worst case, take tens of seconds — the time needed to discover the location of the proxy configuration script, download it, and run the FindProxyForUrl() function within it. This could lead to a hang and unresponsive UI.
  • A site’s Zone can change at runtime without restarting the browser (say, when moving a laptop between home and work networks, or when connecting or disconnecting from a VPN).
  • An IT Department might not realize the implications of returning DIRECT from a proxy configuration script and accidentally map the entire untrusted web into the highly-privileged Intranet Zone. (Microsoft IT accidentally did this circa 2011).
  • Some features like AppContainer Network Isolation are based on firewall configuration and have no inherent relationship to the browser’s Zone settings.

Legacy Edge

The legacy Edge browser (aka Spartan, Edge 18 and below) inherited the Zone architecture from its Internet Explorer predecessor with a few simplifying changes:

  • Windows’ five built-in Zones were collapsed to three: Internet (Internet), the Trusted Zone (Intranet+Trusted), and the Local Computer Zone. The Restricted Zone was removed.
  • Zone to URLAction mappings were hardcoded into the browser, ignoring group policies and settings in the Internet Control Panel.

Use of Zones in Chromium

Chromium goes further and favors making decisions based on explicitly-configured site lists and/or command-line arguments.

Nevertheless, in the interest of expediency, Chromium today uses Windows’ Security Zones by default in two places:

  1. When deciding how to handle File Downloads, and
  2. When deciding whether or not to release Windows Integrated Authentication (Kerberos/NTLM) credentials automatically.

For the first one, if you’ve configured the setting Launching applications and unsafe files to Disable in your Internet Control Panel’s Security tab, Chromium will block file downloads with a note: “Couldn’t download – Blocked.”

For the second, Chromium will process URLACTION_CREDENTIALS_USE to decide whether Windows Integrated Authentication is used automatically, or the user should instead see a manual authentication prompt. (Aside: the manual authentication prompt is really a bit of a mistake– the browser should instead just show a prompt: “Would you like to [Send Credentials] or [Stay Anonymous]” dialog box, rather than forcing the user to reenter the credentials that Windows already has.

Even Limited Use is Controversial

Respect for Zones2 in Chromium remains controversial—the Chrome team has launched and abandoned plans to remove them a few times, but ultimately given up under the weight of enterprise compat concerns. Their arguments for complete removal include:

  1. Zones are poorly documented, and Windows Zone behavior is poorly understood.
  2. The performance/deadlock risks mentioned earlier (Intranet Zone mappings can come from a system-discovered proxy script).
  3. Zones are Windows-only (meaning they prevent drop-in replacement of ChromeOS).

Note: By configuring an explicit site list policy for Windows Authentication, an administrator disables the browser’s URLACTION_CREDENTIALS_USE check, so Zones Policy is not consulted. A similar option is not presently available for Downloads.

Zones in the New Edge

Beyond the two usages of Zones inherited from upstream, the new Chromium-based Edge browser (v79+) adds one more:

  1. Administrators can configure Internet Explorer Mode to open all Intranet sites in IEMode. Those IEMode tabs are really running Internet Explorer, and they use Zones for everything that IE did.

Update: This is very much a corner case, but I’ll mention it anyway. On downlevel operating systems (Windows 7/8/8.1), logging into the browser for sync makes use of a Windows dialog box that contains a Web Browser Control (based on MSHTML) that loads the login page. If you adjust your Windows Security Zones settings to block JavaScript from running in the Internet Zone, you will find that you’re unable to log into the new browser. Oops.


While it’s somewhat liberating that we’ve moved away from the bug farm of Security Zones, it also gives us one less tool to make things convenient or compatible for our users and IT admins.

We’ve already heard from some customers that they’d like to have a different security and privacy posture for sites on their Intranet, with behavior like:

  • Disable the Tracking Prevention, “Block 3rd party cookie”, and other privacy-related controls for the Intranet (like IE/Edge did).
  • Allow navigation to file:// URIs from the Intranet (like IE/Edge did)
  • Disable “HTTP and mixed content are unsafe” and “TLS/1.0 and TLS/1.1 are deprecated” nags.
  • Skip SmartScreen checks for the Intranet.
  • Allow ClickOnce/DirectInvoke/Auto-opening Downloads from the Intranet without a prompt. Previously, Edge (Spartan)/IE respected the FTA_OpenIsSafe bit in the EditFlags for the application.manifest progid if-and-only-if the download source was in the Intranet/Trusted Sites Zone.
  • Allow launching application protocols from the Intranet without a prompt.
  • Drop all Referers when navigating from the Intranet to the Internet; leave Referers alone when browsing the Intranet.
  • Internet Explorer and legacy Edge will automatically send your client certificate to Intranet sites that ask for it. The AutoSelectCertificateForUrls policy permits Edge to send a client certificate to specified sites without a prompt, but this policy requires the administrator to manually list the sites.
  • Block all (or most) extensions from touching Intranet pages to reduce the threat of data leaks.
  • Guide all Intranet navigations into an appropriate profile or container (a la Detangle).
  • Upstream, there’s alongstanding desire to help protect intranets/local machine from cross-site-request-forgery attacks; blocking loads and navigations of private resources from the Internet Zone is somewhat simpler than blocking them from Intranet Sites.

At present, only AutoSelectCertificateForUrls, manual cookie controls, and mixed content nags support policy-pushed site lists, but their list syntax doesn’t have any concept of “Intranet” (dotless hosts, hosts that bypass proxy).


You’ll notice that each of these has potential security impact (e.g. an XSS on a privileged “Intranet” page becomes more dangerous; unqualified hostnames can result in name collisions), but having the ability to scope some features to only “Intranet” sites might also improve security by reducing attack surface.

As browser designers, we must weigh the enterprise impact of every change we make, and being able to say “This won’t apply to your intranet if you don’t want it to” would be very liberating. Unfortunately, building such an escape hatch is also the recipe for accumulating technical debt and permitting the corporate intranets to “rust” to the point that they barely resemble the modern public web.

Best Practices

Throughout Chromium, many features are designed respect an individual policy-pushed list of sites to control their behavior. If you were forward-thinking enough to structure your intranet such that your hostnames are of the form:

Congratulations, you’ve lucked into a best practice. You can configure each desired policy with a * entry and your entire Intranet will be opted in.

Unfortunately, while wildcards are supported, there’s presently no way (as far as I can tell) to express the concept of “any dotless hostname.”

Why is that unfortunate? For over twenty years, Internet Explorer and legacy Edge mapped domain names like https://payroll, https://timecard, and https://sharepoint/ to the Intranet Zone by default. As a result, many smaller companies have benefitted from this simple heuristic that requires no configuration changes by the user or the IT department.

Opportunity: Maybe such a DOTLESS_HOSTS token should exist in the Chromium policy syntax. TODO: figure out if this is worth doing.


  • Internet Explorer and Legacy Edge use a system of five Zones and 88+ URLActions to make security decisions for web content, based on the host of a target site.
  • Chromium (New Edge, Chrome) uses a system of Site Lists and permission checks to make security decisions for web content, based on the host of a target site.

There does not exist an exact mapping between these two systems, which exist for similar reasons but implemented using very different mechanisms.

In general, users should expect to be able to use the new Edge without configuring anything; many of the URLActions that were exposed by IE/Spartan have no logical equivalent in modern browsers.

If the new Edge browser does not behave in the desired way for some customer scenario, then we must examine the details of what isn’t working as desired to determine whether there exists a setting (e.g. a Group Policy-pushed SiteList) that provides the desired experience.


1 Technically, it was possible for an administrator to create “Custom Security Zones” (with increasing ZoneIds starting at #5), but such a configuration has not been officially supported for at least fifteen years, and it’s been a periodic source of never-to-be-fixed bugs.

2 Beyond those explicit uses of Windows’ Zone Manager, various components in Chromium have special handling for localhost/loopback addresses, and some have special recognition of RFC1918 private IP Address ranges (e.g. SafeBrowsing handling) and Network Quality Estimation.
Within Edge, the EMIE List is another mechanism by which sites’ hostnames may result in different handling.

Alongside all the features and improvements in the roadmap for the new version of Microsoft Edge based on the Chromium engine, Microsoft includes a compatibility mode using the Internet Explorer rendering engine to load old websites.

The feature is known as “IE Mode,” and it has been designed for organizations to load internal sites without using a separate browser or having to redesign the site. The new approach loads the pages within Microsoft Edge like a regular website without using and managing multiple browsers.

If you want to start using it, the version of Microsoft Edge available through the stable channel now includes the “Internet Explorer compatibilities” settings to quickly enable IE Mode and a separate option to open Edge when browsing an incomparable website with Internet Explorer. Alongside the settings, it also possible to use the Group Policy Editor to configure the compatibility mode.

In this guide, you will learn the steps to enable IE Mode to load legacy websites using the Internet Explorer rendering engine on Chromium Edge for Windows 10. (You can also watch this video tutorial to configure the feature.)

How to enable IE mode on Microsoft Edge

To enable IE mode on Edge, use these steps:

  1. Open Microsoft Edge on Windows 10.

  2. Click the Settings and More (ellipsis) button on the top-right corner.

  3. Select the Settings option.

  4. Click on Default browser.

  5. Under the “Internet Explorer compatibility” section, turn on the “Allow sites to be reloaded in Internet Explorer mode” toggle switch.

  6. Click the Restart button.

Once you complete the steps, when sites require Internet Explorer, you can use Microsoft Edge to reload the page using IE mode.

Open site with IE Mode on Edge

After the IE Mode is enabled, you need to reload a page with the compatibility mode manually.

To open an incompatible website with IE Mode on Edge, use these steps:

  1. Open Microsoft Edge on Windows 10.

  2. Click the Settings and More (ellipsis) button on the top-right corner.

  3. Select the More tools submenu and choose the “Reload in Internet Explorer mode” option.

After you complete the steps, the website should reload in compatibility mode. If the feature is not enabled, then the option won’t be available in the menu.

If you want to exit IE Mode, you can use the same instructions, but on step No. 3, select the Exit Internet Explorer mode option.

Open Internet Explorer sites on Microsoft Edge

On Windows 10, Microsoft Edge also lets you configure the browser so that when someone is using Internet Explorer incompatible or all sites will load within Edge.

To let IE open websites with Edge, use these steps:

  1. Open Microsoft Edge on Windows 10.

  2. Click the Settings and More (ellipsis) button on the top-right corner.

  3. Select the Settings option.

  4. Click on Default browser.

  5. Under the “Internet Explorer compatibility” section, use the “Let Internet Explorer open sites in Microsoft Edge” drop-down menu and select the option to handle browsing when using Internet Explorer, including:

    • Never – IE will never switch to Edge to load the site.
    • Incompatible sites only – IE will still load sites, but websites designed for a modern browser will load in Edge.
    • Always – IE will always switch to Edge to load websites.

Once you complete the steps, when surfing the web in Internet Explorer, websites will open on Microsoft Edge, according to your configuration.

How to enable IE mode with Group Policy on Microsoft Edge

Alternatively, you can also enable IE Mode on Chromium Edge with Group Policy. However, you will need to download and install the policy template before you can configure the Group Policy settings.

Install Microsoft Edge policy template

To install the policy template to enable IE Mode on Edge, use these steps:

Ie Edge Chromium Extension

  1. Open Microsoft Edge for business website.

  2. Under the “Policy File” section, click the Download button.

  3. Select the version of Microsoft Edge. (Usually, you want to use the latest stable version available.)

  4. Select the build (latest version available).

  5. Select the platform — for example, Windows 64-bit.

  6. Click the Get policy files option.

  7. Click the Accept & download button.

  8. Double-click to open the file.

  9. Click the Extract all button from the “Compressed Folder Tools” tab.

  10. (Optional) Select the location to extract the files.

  11. Check the Show extracted files when complete option.

  12. Click the Extract button.

  13. Browse the following path inside the (extracted) “MicrosoftEdgePolicyTemplates” folder:

  14. Select the msedge.admx and msedgeupdate.admx files and click the Copy option from the “Home” tab.

    Quick tip: You only need to copy the “msedgeupdate.admx” file if you want to control the update settings of Microsoft Edge.
  15. Browse to the following path:

  16. Click the Paste button from the “Home” tab.

  17. In the “admx” folder, inside the “MicrosoftEdgePolicyTemplates” folder, open the language folder that represents your language — for example, en-US.

  18. Select the msedge.adml and msedgeupdate.adml files and click the Copy option from the “Home” tab.

    Quick tip: You only need to copy the “msedgeupdate.adml” file if you also copy the file on step No.12.
  19. Browse to the following path that matches your language:

    In the above command, make sure to change en-US for the folder that matches your language.

  20. Click the Paste button from the “Home” tab.

Ie Edge Chromium Extension

Once you complete the steps, the new policies to enable or disable IE Mode on Edge Chromium will install in the Group Policy Editor.

Enable IE Mode on Microsoft Edge

Chromium Edge Ie Compatibility

To enable IE Mode on Chromium Edge with Group Policy, use these steps:

  1. Open Start.

  2. Search for gpedit and click the top result to open the Group Policy Editor.

  3. Browse the following path:

  4. Double-click the Configure Internet Explorer integration policy.

  5. Select the Enabled option to enable IE Mode for Microsoft Edge.

  6. Under the “Options” section, select the Internet Explorer mode from the dropdown menu.

  7. Click the Apply button.

  8. Click the OK button.

After you complete the steps, websites will render in compatibility mode, and you’ll notice a familiar IE icon on the left side of the address bar letting you know the website is using Internet Explorer.

These steps enable IE Mode for intranet websites. If you want to load external websites using Chromium Edge, you need to enable and set up the “Configure the Enterprise Mode Site List” policy, which includes the creation of an XML file with the list of domains that you want to load automatically with the Internet Explorer mode.

Ie Edge Chromium Based Download

Update February 11, 2021: This guide has been revised with the steps to configure IE Mode on the Chromium version of Microsoft Edge using the new compatibility settings and updated the process to install the Group Policy templates.