FAQ

This message usually appears after you’ve installed an extension from the Windows Store. Be sure to read the permissions required by the extension, and select Turn it on to enable the extension or Leave it off to decide later.

This means Microsoft Edge encountered an error while trying to load the extension from the specified folder. You can see a complete list of these errors by clicking here.

Your device must have the Windows 10 Anniversary Update before you can use extensions. To check what version you have, launch Microsoft Edge, open the More (…) menu, select Settings, and then scroll down to the bottom. Make sure you have version 38.14393.0.0 or later.

For a list supported APIs, extension development guides and troubleshooting topics, head over to the Microsoft Edge Developer Site.

Thanks for helping out! If you find issues while using these extensions, please let us know through the Windows Feedback app.

For the Windows 10 Anniversary Update, we are intentionally starting with a small set of extensions. The list of extensions is locked - you can see the list at our extensions page here. We want to be mindful about what extensions are available on the platform and watch for telemetry and feedback and make sure the reliability, performance and functionality of the browser isn’t impacted by these new features. Extension developers can submit a request to https://aka.ms/extension-request to be considered for a future update.

The Microsoft Edge team maintains Microsoft Edge Platform Status, where you can always find the support status of given web platform APIs. If you’d like to see us support a feature that is currently not available or in development, we want to know! You can share your feedback in the Web Platform Suggestion Box on UserVoice, which the Microsoft Edge team tracks closely as we evaluate new features.

Microsoft Edge has been designed and built to showcase Windows 10 features like Cortana, and is built on top of the Universal Windows Platform. We don’t have any plans to bring Microsoft Edge to Windows 7 or Windows 8.1 at this time.

We want all our customers to be able to experience the unique features we’ve built into Microsoft Edge, which is one of the reasons we’re offering Windows 10 as a free upgrade for Windows 7, Windows 8.1 and Windows Phone 8.1 devices.

Microsoft Edge is the default browser for all Windows 10 devices. It is built to be highly compatible with the modern web. For some enterprise web apps and a small set of sites on the web that were built to work with older technologies like ActiveX, you’ll find a new option that lets you access that site using Internet Explorer 11 on Windows 10.

Microsoft EdgeHTML is the new web rendering engine that powers the Microsoft Edge web browser and Windows 10 web app platform.

Microsoft EdgeHTML began as a fork of MSHTML in early 2014, but has since diverged rapidly. It is designed to be evergreen, with standards-based interoperability at its core.

Going forward, new web standards platform features will be developed for Microsoft EdgeHTML. To preserve compatibility for legacy scenarios, MSHTML will not receive platform updates outside of high priority security and reliability fixes.

The default browser for Windows 10 is Microsoft Edge, which is powered by our new rendering engine and is our path forward for the Web on Windows. Site developers should focus their testing on Microsoft Edge for new and existing experiences. Internet Explorer 11 will be included for some legacy scenarios and users will be have the option to choose it as the default browser, like with any other browser.

You can access the latest preview version of Microsoft Edge by updating to the latest Windows 10 preview via the Windows Insider Program.

In order to run the preview version of Microsoft Edge on a stable version of Windows 10 (or any other OS), you can download a Virtual Machine that we provide or use the upcoming RemoteEdge service.

Yes, Adobe Flash is supported as a built-in feature of Microsoft Edge on devices running the desktop version of Windows 10. We continue to work closely in partnership with Adobe to provide this version of Flash, which we support and service via Windows Update.

To provide a more responsive, reliable, and touch-friendly experience to our customers, we do not support Flash on devices running Windows 10 Mobile.

We’re aligned with other browsers in this transition from Flash towards a modern standards-based web. Starting in EdgeHTML 14, some peripheral Flash content does not play until the user clicks a “play” button. Over time, we will provide users additional control over the use of Flash (including content central to the page) and monitor the prevalence of Flash on the web.

Yes. You can learn more in our blog post, Bringing automated testing to Microsoft Edge with WebDriver, download the Microsoft WebDriver server here or view our WebDriver support and roadmap here.

The web is built on the principle of multiple independent, interoperable implementations of web standards, and we feel it is important to counter movement towards a monoculture on the web. We’ve heard the feedback that MSHTML isn’t a modern engine capable of running today’s modern web. To balance this with the importance of avoiding engine monoculture, we designed our new engine to be significantly more interoperable with Blink and WebKit. We believe that building on that strong foundation gives us the best opportunity to build a world-class browsing experience for Windows for our users and a competitive and interoperable platform for web developers.

While we don’t currently plan to fully open-source Microsoft Edge or EdgeHTML, we understand and value the importance of being more open with our roadmap and our core technologies. Recently, we open-sourced Chakra, the JavaScript engine that powers Microsoft Edge. We’re also making changes to support a more open browser with initiatives like our open roadmap on Microsoft Edge Platform Status, giving more access to our engineers through social media, and collaborating with the major rendering engine contributors, like Adobe, through a shared source program. We’re committed to being even more transparent with the engineering of Microsoft Edge in the future.

Windows 10 UWP apps will always use the most up-to-date version of Microsoft Edge’s rendering engine by default. Win32, WPF and WinForms apps have access to the Edge engine starting in the April 2018 update: https://blogs.windows.com/msedgedev/2018/05/09/modern-webview-winforms-wpf-apps/.

No, ActiveX controls and BHOs such as Silverlight or Java are not supported in Microsoft Edge. The need for ActiveX controls has been significantly reduced by modern web standards, which are more interoperable across browsers. We are working on plans for an extension model based on the modern web platform in Microsoft Edge. We look forward to sharing more details on these plans soon. Not supporting legacy controls in Microsoft Edge has a number of benefits: better interoperability with other modern browsers, increased performance, security & reliability, and reduced code complexity, just to name a few.

In Windows 10, we are delivering Windows as a service, updated on a cadence driven by quality and the availability of new features. We won’t have a fixed schedule for browser feature updates. We’re committed to providing regular updates to our evergreen platform for web developers and customers alike.

Microsoft Edge is an evergreen browser and we will continue to evolve both the web platform and the user interface with regular updates.

• If you are a web developer or designer and have feature requests for the web platform, we encourage you to share your feedback at the Microsoft Edge Platform UserVoice.
• If you are a web developer or designer and have a bug report, please file an issue at the Microsoft Edge Platform Issues site.
• To send feedback on user experience, broken or malicious sites, use the “Send Feedback” menu item in Microsoft Edge

The latest features and platform updates will only be available in Microsoft Edge. We will continue to deliver security updates to Internet Explorer 11 through its supported lifespan. To ensure consistent behavior across Windows versions, we will evaluate Internet Explorer 11 bugs for servicing on a case by case basis.

Microsoft Edge allows localhost access by default but treats “localhost” as an Internet site, so Intranet features like integrated authentication are disabled.

Some custom host mappings might require additional configuration (more on that here) for which you can run the following command:

CheckNetIsolation LoopbackExempt -a -n="Microsoft.MicrosoftEdge_8wekyb3d8bbwe"

In Windows 10 the WebBrowser control will use Internet Explorer’s legacy rendering engine, mshtml.dll. You can replace it with the Edge engine in Win32, WinForms and WPF apps by replacing it with the new WebView control: https://blogs.windows.com/msedgedev/2018/05/09/modern-webview-winforms-wpf-apps/

In some cases, we will load Internet Explorer automatically for sites that don’t work without legacy technologies such as ActiveX.

When Microsoft first set the Do Not Track setting to “On” by default in IE10, industry standards had not yet been established. We are now making this default change as the World Wide Web Consortium (W3C) formalizes industry standards to recommend defaults allow customers to actively indicate whether they want to enable DNT. As a result, DNT will not be enabled by default in upcoming versions of Microsoft’s browsers, but we will provide customers with clear information on how to turn this feature on in the browser settings should they wish to do so.

Yes. In Universal Windows Apps built for Windows 10, the WebView control use Microsoft EdgeHTML. WebView controls in apps built for Windows 8 & 8.1 will continue to load the MSHTML to preserve compatibility.

The Microsoft Edge user agent string is:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/<Version #> (KHTML, like Gecko) Chrome/<Version #> Safari/<Version #> Edge/<Major Version #>.<OS Build #>

On Windows 10 phone devices, it is:

Mozilla/5.0 (Windows Phone 10.0; Android 4.2.1; DEVICE INFO) AppleWebKit/<Version #> (KHTML, like Gecko) Chrome/<Version #> Mobile Safari/<Version #> Edge/<Major Version #>.<OS Build #>

Note that we recommend avoiding user agent string detection if at all possible and sending Microsoft Edge the same content that you send other modern browsers. We will be iterating regularly on the Edge version number, including updating the Chrome, WebKit, and Safari version numbers, to ensure the most interoperable content is served to Microsoft Edge. Developers should only look at the version when targeting specific bug fixes.

For some non-interoperable/app-related scenarios, such as extensions, analytics, links to app stores, and pinned sites, you should use the “Edge” token and major version to detect Microsoft Edge and send us the correct metadata.

Web browser user-agent strings are used to ensure that web servers deliver the best content to be rendered by the browser. Microsoft Edge has been built with a strong focus on modern web interoperability and leaving behind Internet Explorer-specific code patterns. The new user-agent string was carefully tested to ensure that we get that modern web code without web developers having to update their sites.

The pattern of web browsers including each other’s user-agent string tokens has happened repeatedly over the history of the web - as an example, all browsers include “Mozilla/5.0” for this reason. For more background, see the related discussion (video) from the Microsoft Edge Web Summit.

For full-fidelity testing and debugging, you can use the free version of Visual Studio to remotely debug Internet Explorer on Windows Phone 8.1. You can learn more about this in our video, How to remote debug a HTML5 website on Windows Phone/Mobile IE using Visual Studio 2013.

Remote debugging for Microsoft Edge on Windows 10 Mobile Preview is in development and is not yet available. For basic testing and debugging, you can use the F12 Developer Tools in Microsoft Edge on a Windows 10 PC, which is powered by the same EdgeHTML rendering engine. In the F12 Developer Tools, select “Emulation” and change the Browser Profile dropdown to “Windows 10 Mobile.”

Starting in EdgeHTML 13, unsigned modules are blocked from running inside Microsoft Edge. If you are a device driver developer, you may need to test using a device driver that has not yet been WHQL-signed. To disable the DLL security protection and enable your unsigned driver to run inside Microsoft Edge, you must enable the “testsigning” boot configuration as described here.

Thanks for taking the time to share your feedback! To make it easier to open bugs against Edge, we now can file bugs automatically based on tweets with the hashtag #EdgeBug. To automatically file a bug from a tweet, we need a linked test case on CodePen, JSFiddle, JS Bin, GitHub Gist, or dabblet. You can learn more about what makes a good reduction in our blog post here.

Don’t have a reduction? We can still open a bug, but we’ll need your help:

• If you have consistent steps to reproduce an issue, please open a bug on issues.microsoftedge.com with as many details as possible.
• If you have a broken site that doesn’t render correctly, but can’t reduce the issue yourself, you can Send Feedback from within the Microsoft Edge menu (“…”) and select “Broken site issue.”
• If you have a suggestion or idea to add a new feature to the Microsoft Edge app itself, you can Send Feedback from within the Microsoft Edge menu (“…”) and select “Open feedback hub.”

Stuck? You can always reach out to us on Twitter: Just ping @MSEdgeDev and we’ll be happy to help out!

We crawled a curated set of unique pages to be relatively representative of the web. This set includes top sites from all over the globe and random sites that have very low ranking. Additionally we ensured that half of these pages were sub pages so that we didn’t only crawl landing pages. We wanted these crawls to be very representative of the web as whole to ensure that

Browser Versions
Chrome 49: 598,047 pages
MS Edge 14: 620,254 page
Total Pages Crawled: 1,218,301

We are running these crawlers on Windows VMs on Azure and we don’t currently have a manner in which to run Safari within the crawler due to Safari being available on OSX and iOS, respectively.

Yes! We open sourced the script and we look forward to seeing what the community feels should be tracked. There is work that has to be done on at Microsoft in order to get the new information rolling up and onto the site. Read through the readme on GitHub Repo to begin contributing and providing more data from across the web.

The goal of this data is to be device agnostic, because the web should be right? However, right now we start up each browser in its default state with a device pixel ratio of 1, and provide it with the default UA string with no emulation set. Due to this, we will normally get the desktop site unless we are navigating to a mobile only site that doesn’t redirect based on viewport or UA string to the desktop site. Basically, the goal of this will be to report what the web uses across every device. As anyone working with the web in any capacity should not be focusing on a single device form factor to inform their decisions if they can help it. With that said, we do have a desire to try and capture this information down the road. We do go inside of any media-query (whether it evaluates to true or not) so any sites built in a responsive way will be gathered.

Yes and no. In order to fully understand everything that would have been used, we act as though we’re every device so we go into every media query, remove most pseudo classes and any other variable that could limit us retrieving all of the CSS information that could be applied to the page. Because of this, maintaining which value would have won is quite complex and adds a lot of additional computation overhead to the script, for what we see as very little additional value. Additionally, this makes it complex on the user experience of the site as we would need to allow the user to see values that triggered only at certain viewport widths, with or without triggered pseudo classes, and the various media queries.

Yes and No. Some information that we desire to have would be best via the actual browser, and some of this we do already receive internally. However, some questions become quite cost effective to implement into the browser and do so in a performant manner. Additionally, once the data is being collected from actual users, that data needs to have all personal information removed and we probably couldn’t provide as much rich information. Where feasible, we will be providing in browser telemetry to supplement the data provided by crawlers.

This is because when a browser sees margin: 5px 10px 15px 5px this gets computed to the long hands of margin-top: 5px, margin-right: 10px, margin-bottom: 15px, and margin-left: 5px. This is the same for all other short-hands except for an instance where the browser can’t determine which shorthand the value should go to. An example of this is padding showing up padding where the only value is a var(). So, if you’re interested in shorthand information, look to the long-hands that the shorthand gets expanded to. We are however looking into this issue to make it less confusing for people reviewing the data.

No. We do have a desire to get this however and we have prototyped some ways in which to gather this information (in addition to gathering it via the browser itself). We do feel it’s very important to get this data as a logged in user can receive very different pages than a logged out user. If we do determine a way in which to accomplish this, we’ll update you here or and on the MS Edge Dev Blog.

We are iterating over the CSSOM to determine what CSS was accepted by the engine’s parser. This serialization is determined by the CSSOM L1 Specification and hexadecimal values are supposed to be serialized into rgba().

Not necessarily. The API data here is obtained from enumerating each browser’s DOM. If an API is marked as implemented, it indicates that the API exists within the browser. Test were not run to verify the quality or functionality of the API.

We extract API information from specifications by scraping IDLs from standards documents.

Currently we have only processed the specifications listed. In the future, we plan to expand that list in the future using the references defined in http://www.specref.org/.

This could due to a few reasons:

1. The API might exist elsewhere in the prototype chain and is actually inherited.
2. This might actually be a bug in the data. Please create an issue in this Github repository.

Length is implemented in a different place in the prototype chain and not on the instance as defined by the specifications.

The data is gathered from the latest publically available version of each browser.

Unfortunately no. At this time, only interfaces and APIs exposed on Window are collected.

It’s powered by venn.js, an open source library distributed by MIT license.