This blog is closed as of 2/2015. @EricLaw left Microsoft in 2012, but was named an IE MVP in '13 & an IE userAgent ( in '14.

Internet Explorer 11’s Many User-Agent Strings

Internet Explorer 11’s Many User-Agent Strings

  • Comments 39

If you found this post, chances are good that you’re searching for IE11’s User-Agent string.


Were you planning to control your website’s behavior based on the browser “sniffed” from the User-Agent (UA) string?

Please don’t; use feature detection instead (Ref1, Ref2).

Poorly implemented (non-futureproof) User-Agent sniffing has proven to be the top compatibility problem encountered each time a new version of Internet Explorer ships. As a consequence, the logic around the user-agent string has grown increasingly complicated over the years; the introduction of Compatibility Modes has meant that the browser now has more than one UA string, and legacy extensibility of the string was deprecated after years of abuse.

By way of example, consider...

ASP.NET User-Agent Sniffing

Pages running on ASP.NET might use UA sniffing to decide what content to return to browsers. You will need to ensure that hotfix is installed on your servers for ASP.NET to recognize IE11 as a browser that supports JavaScript:

  • 2836939 .NET 4 - Win7SP1/Win2K3SP2/Win2K8R2SP1/Win2K8SP2/VistaSP2/WinXPSP3
  • 2836940 .NET 3.5 SP1 - Win2K3SP2/Win2K8SP2/VistaSP2/WinXPSP3
  • 2836941 .NET 2.0 SP2 - Win2K3SP2/WinXPSP3
  • 2836942 .NET 3.5 SP1 - Win7SP1/Win2K8R2SP1
  • 2836943 .NET 2.0 SP2 - Win7SP1/Win2K8R2SP1
  • 2836945 .NET 2.0 SP2 - Win2K8SP2/VistaSP2
  • 2836946 .NET 2.0 SP2 - Win8RTM/WinRTRTM/Win2K12RTM
  • 2836947 .NET 3.5 SP1 - Win8RTM/WinRTRTM/Win2K12RTM

Without the hotfix's updated browser definition file, your pages might omit the script blocks from all pages sent to an IE11 client.

See why UA-sniffing is evil?

IE11's Default UA String

By default, Internet Explorer 11 on Windows 8.1 sends the following User-Agent string:

    Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko

This string is deliberately designed to cause most UA-string sniffing logic to interpret it either Gecko or WebKit. This design choice was a careful one—the IE team tested many UA string variants to find out which would cause the majority of sites to “just work” for IE11 users.

Contrast this string with the old IE10 on Windows 8 UA string:

    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

Many websites would scan for the MSIE token and, if present, return non-standard markup which would not render properly in modern versions of IE.

DOM userAgent Property

Internet Explorer 11 continues the IE9 tradition of exposing extensible tokens in the navigator.userAgent property but not sending those tokens in the request header. For instance, by default this property returns the following on IE11/Win8.1:

    Mozilla/5.0 (Windows NT 6.3; Trident/7.0; .NET4.0E; .NET4.0C; rv:11.0) like Gecko

The .NET tokens here were pulled from the registry and allow JavaScript to detect that the .NET Framework is installed on the computer. (They’re a bit misleading because Windows 8.1 includes the 4.5 version of the Framework.)

Compatibility View

If the user chooses to render a site in Compatibility View (click Tools > Compatibility View Settings) then IE will send a User-Agent string that mimics Internet Explorer 7’s UA string:

    Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; Trident/7.0; .NET4.0E; .NET4.0C)

By default, sites in the Intranet Zone render in Compatibility view, so this is the User-Agent string they’ll see.

Compatibility View List

Internet Explorer 10 introduced the ability for the downloaded Compatibility View List to specify arbitrary UA strings on a per-site basis, to handle cases where a given website only works with a particular UA string.

If you use Fiddler to examine the XML of IE11’s Compatibility View List (e.g. you will see that it contains a number of UA strings:


…each of which can be sent to a particular domain to help ensure that it renders properly in IE10+:



Obviously, maintaining Compatibility View Lists requires a significant investment on the part of the IE team—resources which could be used to implement more new standards, performance improvements, etc. Please please please: use feature detection rather than User-Agent sniffing.



PS: Also note that in IE11 mode, the navigator.appName property returns Netscape; older versions returned Microsoft Internet Explorer. The new value matches all major browsers including Safari, Chrome, and Firefox.

  • Great post, as usual, on a confusing topic.

  • Nice explanation Eric, and I definitely appreciate the "Please don't; use feature detection instead..." remark. So important. I have been taken aback by the number of sites I've seen that tell me I need to upgrade my browser to IE8 in order to use their site even though I'm using IE11. So many...

  • How will conditional comments work in IE11, will it be renamed to Trident there also? E.g. <!--[if IE]> ? And how will X-UA-Compatible behave in IE11?

    [EricLaw] X-UA-Compatible's behavior remains the same as it was in IE8, IE9, and IE10. Conditional comments are respected only in IE5, IE7, IE8, and IE9 document modes; IE10 and IE11 document modes ignore conditional comments as other modern browsers do.

  • As a user, I love that pages which work crappy in IE and after digging a little, I find that the webmaster just assumed that IE7 is the latest IE and there won't be any new IE...

  • Any chance of an ASP.NET hotfix to remove UA sniffing and assume everything is "uplevel", rather than just adding the new UA strings to the list?

  • @Richard: I believe there's some way for a site author to do something like that manually (by setting an "uplevel" property somewhere). I don't actually know how the new browser definition files work, but I've heard that the IE team is engaging with the ASP.NET team on providing a more forward-looking approach.

  • Thanks for this run-down, particularly of the Fiddler tool to apply a particular UAS to a particular site.

    However, my IE11RP on W7SP1 is sending a UAS that differs from the 'standard' one, and I'd like to know how to correct it. This is what reports:

    Mozilla/5.0 (MSIE 10.0; Windows NT 6.1; WOW64; Trident/7.0; EIE10;ENUSWOL; rv:11.0) like Gecko

  • Wow !Firedog, that's the Farmer in the Dell's UA string.

    EIE10 = E I E I O

  • @Firedog: See, a script that will grovel your registry to find any tokens that might be corrupting the UA String. The script will drop reg.txt on your desktop, email that file to me and I'll have a look.

  • @EricLaw: Unfortunately, the Page.ClientTarget property [1] has to be set on every page for that to work. It also seems to use an IE6 UA [2], which isn't my idea of an "up-level" browser!



  • @Richard: You can set Page.ClientTarget to any value that's listed in clientTarget elements in your app's web.config, or anything that it inherits. What [1] is saying is that by default there are only two clientTarget elements defined in %SystemRoot%\Microsoft.NET\Framework\v4.0.30319\Config\web.config. These map an alias to a User-Agent string, which is then processed by the .browser files to set the Request.Browser properties.

    "uplevel" is defined as "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1)" To be identical to IE 6.0 it should be Mozilla/4.0, not /5.0, but the browser caps detection doesn't actually check the Mozilla version (just that the token is present), so this doesn't matter.

    "downlevel" is defined as "Generic Browser", which is detected in generic.browser.

    To treat everything as some version of Chrome 19, say, you could add a clientTarget element to your web.config:


     <add alias="chrome19" userAgent="Mozilla/5.0 (Windows NT 6.2) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5" />


    and then set Page.ClientTarget to "chrome19".

    Then ASP.NET would treat all incoming browsers, regardless of the actual User-Agent string, as Chrome 19 (and therefore, hopefully, serve up standards-compliant code).

  • @Mike Dimmick: You still need to set the property on every page though. It would be nice if there was an application-level switch you could set to tell ASP.NET to always serve up standards-compliant markup.

  • Sorry, but sometimes feature sniffing is not sufficient. For example, postMessage works for other browsers to send messages from pop-up windows, but this does not work in IE with any version. How would you sniff for that? It has the feature, but it doesn't work the same way.

  • We have two issues with IE11 tied to the agent string change; we have been in the process of bringing all apps up to modern web standards, but unfortunately are still 3 to 6 months away from finalizing the changes.

    1) We have about 20 complex intranet applications used by thousands of users. Historically, we supported IE only, and had added Firefox support over the years to half of the applications (we're a non-profit with very limited testing resources and a controlled intranet environment), with a MasterPage that blocks access for user agents that don't contain MSIE or Firefox; the MasterPage is compiled into a single app assembly in most cases, so we cannot simply replace a MasterPage assembly, and any Page directive changes in content pages would also require recompilation and retesting of these 20 apps because our apps are precompiled and don't allow content changes on the server.  For several months, we have been in the process of migrating all of our apps to standards compliance and feature detection to allow IE, FF, Chrome, etc.  However, we are still 3 to 6 months away from completion of this and are looking for a server or config setting we can use in the meantime that allows our IE11 users on Win7 and Win8.1 to access our non-converted apps as if the browser were IE10. Our only alternatives so far are to tell people to switch to Firefox, or to open the IE F12 tools for each browser session and set the agent string to IE10 there.  We currently use an X-UA-Compatible setting of IE=IE10;IE=IE9;IE=8 in these apps.  We cannot ask users to add our domain to compatibility settings because this messes up the viewing of other sites within our domain.  Any short-term suggestions?

    2) We have a few vital legacy applications from 2003 running in .NET 2.0 and built using many TreeView controls from the IE Web Controls 1.0 package.  These applications use an X-UA-Compatible setting of IE=EmulateIE7, and work great in IE8 through IE10.  However, the TreeView controls do not render or function properly in IE11 and are unusable, so I suspect the framework or the controls are looking at the agent string, and the EmulateIE7 setting is being ignored (or there is a bug in IE11 in how it presents IE7 compatibility mode).  IE10 Preview had a similar issue that was fixed in the final IE10, so I'm hoping the final IE11 may also fix this issue.  Our only solution so far is for each user to use F12 tools to set the user agent string manually to IE10, IE9, IE8, or IE7, all of which render the TreeView controls properly.  We are planning to rewrite these legacy apps using modern web standards, but that will be a 6+ month project, and isn't planned to start for at least another year.  Any workarounds or fixes to IE11 in the meantime would be very helpful.

  • How often does IE re-download the compatibility view list/check for an updated list?  This is particularly relevant today as Google appears to have updated their sites to work in IE11 natively, but this is causing problems for many users as it was set to EmulateIE10 in the CV list.  If I go to the online version of the list linked above it appears to be a newer version with the Google sites removed, but my local copy hasn't yet updated.

Page 1 of 3 (39 items) 123