FAQ

This message appears when an updated version of the extension has been installed from the store.

This usually means that Microsoft Edge cannot access the extension folder you attempted to load. Try deleting the extension folder, running the .EXE again and then loading the extension folder that was created in your Downloads folder.

At this time, only specific preview builds of Microsoft Edge support extensions.

Make sure you’re a part of the Windows 10 Insider Program and running preview build 14291 or greater.

You can enable developer features for extensions via about:flags. More detailed info on debugging, supported APIs, troubleshooting, etc. is available on the Microsoft Edge Developer Site.

The extensions on this page represent the work of a small group of extension authors. This webpage is only temporary and in the future users will be able to download extensions from the Windows Store.

We plan to share more information on publishing your own extensions at a later date.

We suggest you not download extensions from any site other than dev.windows.com. Our team has gone to great lengths to verify the legitimacy of the extensions on this page. So we accept no responsibility for any damage caused by extensions obtained from any other source.

In a future update, you’ll be able to download extensions from the Windows Store.

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. We continue to work closely in partnership with Adobe to provide this version of Flash, which we support and service via Windows Update.

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

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 WebOC hosting of EdgeHTML.dll is not supported in Windows 10 at this time.

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 single sign on are disabled.

In Windows 10 the WebBrowser control will use Internet Explorer’s legacy rendering engine, mshtml.dll. At this time EdgeHTML is not available through the WebBrowser control.

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 latest stable Microsoft Edge user agent string is:

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

On Windows 10 phone devices, it is:

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

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, so 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 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, you can watch this video from the Microsoft Edge Web Summit (user-agent discussion starts at 9:45).

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 disable SecureBoot, and then set the DWORD value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\CodeIntegrity!DisableCIChecks to 1.

RemoteEdge is completely free. You are only required to register using a Microsoft Account.

Yes, RemoteEdge is the latest evolution of the IE developer channel. We know that developers who may not have Windows 10 devices want a way to test the latest builds of IE, so we built RemoteIE to bring a single, low-friction solution to both downlevel Windows as well as other platforms like Mac OS X, iOS and Android.

RemoteEdge is built on top of Azure RemoteApp Preview. You are running IE/MSEdge as a service from a virtualized environment shared with other users so the performance will not be the same as if you were running it natively. Because it is virtualized, GPU acceleration is disabled. This means that WebGL websites will be software rendered.

Yes, unless there is any technical limitation you will be running the latest version available of IE/MSEdge on Windows 10 Technical Preview for Enterprise.

This is something that is definitely on our radar. Let us know if this is something that would be valuable to you! One thing to keep in mind is that RemoteApp runs on top of Windows Server 2012 R2 or better so the versions available will be IE11 and IE11 in Enterprise Mode. Sorry, no IE6.

Great! Send us a tweet to @MSEdgeDev

In this preview version of the service, only publicly accessible URLs and IP addresses can be accessed although there are some third party services (like ngrok) that can help you with this.

Remote is not meant to replace your regular browser. You should only use it to test new features available in IE. Things like add-on installation, favorites and history are disabled or deleted on a regular basis.

Yes! Just press F12 or go to Tools -> F12 Developer tools and you are ready to go.

Currently you will be disconnected after 10 minutes of inactivity. You will also be disconnected after 60 minutes even if you are active. In this preview of the service, we need to balance out load and demand on the servers and monitor capacity closely. Over time, these limits could be tweaked to better balance out resources and user demands. There aren’t any limits in the number of sessions you can have in a day as long as there are resources available. If too many users are connected, you will receive a message asking you to wait for a few minutes and try again.
Additionally, users will be removed who haven’t used the service for a long period of time. Of course, you will be able to sign up again with no problem.

Send as a message via Twitter at @MSEdgeDev.

Yes! Just log in using your Microsoft Account and update your region. You will receive an email once it is done.

Due to RemoteApp limitations, we aren't currently able to offer a remote version of Microsoft Edge. Remote loads the TH2 version of EdgeHTML. Rest assure, we are working hard on this and this feature will ship as soon as it is ready.

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 would love to crawl with Firefox, and have reached out to them to see if they would be willing to provide a way to spin up their browser with access to external CSS stylesheets. Since this currently isn’t possible we don’t want to include their numbers as we don’t want those to affect the data we’re providing to the community.

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.