Internet Explorer 11’s Many User-Agent Strings

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.

Comments (39)

  1. Tony Chor says:

    Great post, as usual, on a confusing topic.

  2. John Jansen [MSFT] says:

    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…

  3. Samuel says:

    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.

  4. Kirill says:

    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…

  5. Richard says:

    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?

  6. @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.

  7. ¡Firedog says:

    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

  8. Phil Hartfield says:

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

    EIE10 = E I E I O

  9. @Firedog: See…/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.

  10. Richard says:

    @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!



  11. Mike Dimmick says:

    @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.NETFrameworkv4.0.30319Configweb.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).

  12. Richard says:

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

  13. Jacob says:

    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.

  14. GRH says:

    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.

  15. fr says:

    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.

  16. Neil says:

    This issue seems to cause an infinite redirect loop if you are using forms authentication in 4. I believe its because 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.

  17. ddcohen says:

    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.

  18. Kevin Sours says:

    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.

  19. Kevin Sours says:

    I guess that RFC (…/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).


  20. bill says:

    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.

  21. Jim says:

    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.

  22. Jim says:

    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.

  23. PhistucK says:

    @Jim –

    I suppose the focus event is fired within the iFrame, if it acquires the focus. Have you tried checking that?

  24. ne says:

    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.


    I'm the guy that reads the weblogs from IIS and tries to determine how to allocate testing resources.

  25. says:

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

  26. Damon Wood says:

    We've managed to remove 99% of legacy user agent-driven logic from our product over the years, but the application — which is basically an e-learning web app using media delivered by either a CDN or an intranet-hosted media server — is still just complex enough that we need to be able to do advance triage for a prospective client and  troubleshoot effectively when clients have issues. (Our clients generally come with anywhere between 100 and 10,000 users)

    Even though the delta between actual usable configs and our official line of supported browsers has gotten smaller and smaller, for years Internet Explorer has been the only browser we technically support. The reason for this is that most of our customers can be guaranteed to have MSIE on their corporate desktop/laptop/etc. and — in general — the application we developed had been easiest to support with IE (though this has become less reliably so, admittedly). Anyway, drawing the line at MSIE has made life much easier on our support team, who can point to our requirements and say if you're not using IE, we can't spend valuable time working out whatever issue you're having with Firefox, Chrome, etc.

    So we have a simple self-help web application (called a "QuickCheck") whose sole purpose is to diagnose whether a client's browser/OS/plugin configuration meets our minimum requirements, and we've happily been spitting out the browser type and version just as a matter of course, since it provides a simple baseline requirement that can point people in the right direction if they are having an issue with our product.

    Even though the application our clients pay for doesn't shut the door on, or otherwise tailor the experience for, browsers other than MSIE (and when we do it's a feature-based switch, not a sniff), in the QuickCheck we DO want to identify the browser specifically, and we've been doing this reliably with the user agent. (User agent spoofers can sometimes get around it, but this is not a big problem for us.) You can see that this is all going to change shortly.

    It's a changing world out there, and since our app is over 10 years old now you can guess we've had to scramble to adapt more than once. Personally, I am so glad that most core browser functionality is pretty well supported in a standard way.

    However I just wanted to point out that there are, at times, legitimate uses for a user agent sniff.

  27. Enno Ostendorf says:

    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.

  28. ds says:


    No need to add the Page.ClientTarget to each page. Instead, add to Global.asax.cs

    protected void Application_PreRequestHandlerExecute(Object sender, EventArgs e)
    var page = (Context.Handler as System.Web.UI.Page);
     if (page != null)  {                
        page.ClientTarget = "chrome19";

  29. Ivo says:

    And what features should I detect if I need to know, whether the browser supports clickonce (as we unfortunately need it at the moment)?

    [EricLaw] You don't need the browser to "support" ClickOnce if you author your .application file properly. Any browser (e.g. IE, Chrome, Firefox, Opera, etc) will download the file and allow the user to execute it.

  30. says:

    @Ivo – Maybe…/dn423948(v=vs.85).aspx would be of help in this situation? (Check navigator.plugins for the ClickOnce plugin)

  31. Is Mozilla necessary? says:

    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.

  32. Victor says:

    Is there a way to use feature detection for bug…/781964?

  33. John H. says:

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

  34. Marcin Sciesinski says:

    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:…/internet-explorer-cannot-download-over-https-when-no-cache.aspx

  35. says:

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

  36. senvr says:

    How can I permanently change IE user agent string? I need IE11 to always use the IE9 user agent string

  37. Angry says:

    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.

  38. says:

    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.



  39. HomeCloset says:

    > 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.…/announcing-improvements-to-the-enterprise-mode-site-list.aspx

Skip to main content