Internet Explorer 11’s Many User-Agent Strings

發行項
09/21/2013

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

Why?

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. https://iecvlist.microsoft.com/IE11/1375395130872/iecompatviewlist.xml) 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.

thanks,

-Eric

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.

Comments

Anonymous
September 21, 2013
Great post, as usual, on a confusing topic.
Anonymous
September 21, 2013
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...
Anonymous
September 22, 2013
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.
Anonymous
September 22, 2013
The comment has been removed
Anonymous
September 22, 2013
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?
Anonymous
September 23, 2013
The comment has been removed
Anonymous
September 23, 2013
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 winware.org reports: Mozilla/5.0 (MSIE 10.0; Windows NT 6.1; WOW64; Trident/7.0; EIE10;ENUSWOL; rv:11.0) like Gecko
Anonymous
September 23, 2013
Wow !Firedog, that's the Farmer in the Dell's UA string. EIE10 = E I E I O
Anonymous
September 23, 2013
@Firedog: See www.enhanceie.com/.../GetUAOverrides.bat, 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.
Anonymous
September 23, 2013
@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! [1] msdn.microsoft.com/.../system.web.ui.page.clienttarget.aspx [2] msdn.microsoft.com/.../6379d90d%28v=vs.100%29.aspx
Anonymous
September 23, 2013
The comment has been removed
Anonymous
September 23, 2013
@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.
Anonymous
October 03, 2013
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.
Anonymous
October 11, 2013
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.

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?
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.

Anonymous
October 19, 2013
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.
Anonymous
October 22, 2013
This issue seems to cause an infinite redirect loop if you are using forms authentication in asp.net 4. I believe its because asp.net thinks ie11 doesn't support cookies and so redirects user to login app, which then recognises that the user is already logged in and redirects back to original app, starting the loop.
Anonymous
October 30, 2013
Is there a version of this hotfix for .NET 4.5? [EricLaw] Per Scott Hanselman, ASP.NET4.5 doesn't have this issue. If you're having problems, you might read his post to see if there are outdated configuration files on your server.
Anonymous
October 31, 2013
How do we use feature detections to properly work around the fact that IE still doesn't handle "application/json" per internet standards? EricLaw: I'd love to learn what standard you believe is violated and specifically how.
Anonymous
October 31, 2013
I guess that RFC (www.ietf.org/.../rfc4627.txt) states that it is not actually an Internet standard. However appears to be widespread agreement that "application/json" is the correct content type for json responses. However, if you send documents to IE with that type, it will prompt the user to download the response. This does not play well with AJAX applications.

EricLaw: There's nothing in RFC4627 that states what a user-agent should do when attempting to navigate to application/json, and for good reason. Generally speaking, browsers should treat as downloads anything they don't have a particular native rendering for (e.g. an iCAL appointment file, etc). There are a number of reasons for this, security is one of them. By treating the file as a download rather than a very poorly formatted HTML document, for instance, you prevent script-injection attacks against JSON services. The claim "This does not play well with AJAX applications." is nonsensical. AJAX applications download JSON using the XmlHttpRequest object, which doesn't care about what the target MIME type is, and which will never trigger a file download dialog, regardless of the MIME type. A File Download dialog only renders if you attempt to navigate to a document of a MIME type for which the browser does not have a native renderer (or if it does have a native renderer but you've specified Content-Disposition: attachment).
Anonymous
November 18, 2013
That is all great and wonderful for future development, but when you're trying to maintain hundreds of thousands of lines of code and have to change every place where the browser is sniffed, it becomes a major, major undertaking. [EricLaw]: Indeed, ongoing maintenance cost is one of the reasons that browser sniffing is discouraged. Rather than updating sniffing, it's best to remove it and replace with feature detection.
Anonymous
November 20, 2013
How do you feature detect whether this will work? addEventListener('DOMAttrModified' ....addEventListener is present in IE and Chrome, yet DOMAttrModified is not supported by Chrome, only IE. [EricLaw] For scenarios like this, the obvious approach would be to add the event handler, add a temporary DOM element, modify its attribute, and if the event doesn't fire you know that it's not supported. There may be a better approach, but that pattern is used by modern feature detection frameworks.
Anonymous
November 22, 2013
Your tip for 'DOMAttrModified' is helpful, thanks. However there are still other times that it's not possible - eg I'm updating code relating to selections, in Chrome if you do sel.addRange(range) then focus is not put back in the iframe, whereas for IE it is (which makes a difference for me). Don't see how you can detect that in code. I don't expect you to have a way to do that, my point is really that while homogeneity is a nice ideal, in reality you can't escape the fact that browsers are different and even with perfect adherence to standards, there will always be fuzzy edges.
Anonymous
November 23, 2013
@Jim - I suppose the focus event is fired within the iFrame, if it acquires the focus. Have you tried checking that?
Anonymous
December 04, 2013
To answer the question that headlines the post: "If you found this post, chances are good that you’re searching for IE11’s User-Agent string. Why?" I'm the guy that reads the weblogs from IIS and tries to determine how to allocate testing resources.
Anonymous
December 04, 2013
We have a need to know if the browser is IE10 or IE11 in order to disable a feature in our Silverlight app. Our pages emulate IE9. When we run HTML reports using Crystal Reports, they fail if the browser is IE10 or IE11. The failure occurs no matter what IE Emulation we use (or none) and compatibility view makes no difference. This is a known bug in Microsoft IE that some POSTs to the server don't include the body because they expect the server is going to return a redirect (which it does not). [EricLaw] No such bug exists. Perhaps you're referring to a server-configuration problem, I wrote about here: http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication-challenges-are-expected.aspx? I'd be happy to see a repro of this as a Fiddler log; simply email it to me. So, in short, we would like to put logic in our code to say if the browser is IE10 or IE11, disable the feature (since it can't be made to work). As it stands, we are planning to just disable the feature if it is any version of IE because we can't tell if it is just 10 or 11. Is there any way? [EricLaw] Modern IE versions, including IE11 include a Trident token in the User-Agent string.
Anonymous
December 05, 2013
The comment has been removed
Anonymous
December 10, 2013
IE11 on Win7 UserAgent is IE10, not distinguishable from IE10. [EricLaw] That is incorrect. IE11 has a bug in Date.toLocaleTimeString(): Date().toLocaleTimeString().length is 13, should be 8, here IE11 can be distinguished from IE10. [EricLaw] That doesn't really make sense. toLocaleTimeString's length depends on the time-of-day. If the string in question changed from IE10 to IE11, that's probably because IE11 better supports the standard for internationalization.
Anonymous
December 17, 2013
The comment has been removed
Anonymous
December 19, 2013
The comment has been removed
Anonymous
December 20, 2013
@Ivo - Maybe msdn.microsoft.com/.../dn423948(v=vs.85).aspx would be of help in this situation? (Check navigator.plugins for the ClickOnce plugin)
Anonymous
January 03, 2014
Did you consider replacing the Mozilla token? This was useful in the IE3 days, but are there really any websites still sniffing for it that actually work in IE11? [EricLaw] Yes, many websites depend on this token today. You can use the F12 Developer Tools or Fiddler to set the UA string to anything you like and watch what breaks. Of course, keep in mind that the IE Compatibility team tests hundreds of thousands of sites (or more), so they have a better picture of what breaks than most.
Anonymous
January 09, 2014
Is there a way to use feature detection for bug connect.microsoft.com/.../781964?
Anonymous
April 24, 2014
How can one get a browser's file upload size limit without User-Agent sniffing? [EricLaw] Typically, a site should probably be using XmlHttpRequest to upload chunks of a file loaded using the File API, which eliminates any sort of "limit." For downlevel browsers, it's not clear what exactly you'd do differently based on the limit (which isn't the part of any browser's formal contract and thus is subject to change in updates).
Anonymous
July 10, 2014
You recommend to use "Feature Detection" rather than browser detection. However, how are we supposed to work-around IE specific bugs, if we can't detect it due to the browser "deliberately lying"? For example this one? We had a fix on the server in place that was ensuring the caching headers were not present for clients sending in User-Agent containing "MSIE", but we can't do this anymore! Issue we were trying to work-around: blogs.msdn.com/.../internet-explorer-cannot-download-over-https-when-no-cache.aspx
Anonymous
July 10, 2014
@Marcin - I think this is a legitimate case of user agent detection, so just detect "Trident" or "MSIE". "Trident" exists since Internet Explorer 8 or 9, I believe.
Anonymous
July 23, 2014
How can I permanently change IE user agent string? I need IE11 to always use the IE9 user agent string
Anonymous
July 31, 2014
If the X-UA-Compatible has been set to IE=9, IE11 should send the IE9 user agent string not the IE11 user agent string!. [EricLaw] It's not clear how you imagine that would work. IE sends the User-Agent in the Request header. It's not until the Response to that request is received that it gets the Server's X-UA-Compatible directive.
Anonymous
November 25, 2014
If I understand things correctly, "Compatibility View" via the IE UI turns on IE7 mode. "Enterprise Mode" (introduced relatively recently) puts IE into IE8 mode. There does not seem to be a way to programmatically (via GPO for example) force IE11 into IE9 or IE10 mode, likewise there doesn't appear to be a way to programmatically change the UA string without using "Compatibility View" or "Enterprise Mode." We have a number of sites that would work fine if we could force IE10 or a different UA string but there's no way as an admin to do this. Am I missing something? This seems like such an oversight and it would fix so many problems. Thanks, James
Anonymous
December 01, 2014
> There does not seem to be a way to programmatically (via GPO for example) force IE11 into IE9 or IE10 mode Not entirely correct today. blogs.msdn.com/.../announcing-improvements-to-the-enterprise-mode-site-list.aspx

共用方式為