The Internet Explorer 8 User-Agent String (Updated Edition)
As announced in February 2008, Internet Explorer 8 sends an updated user-agent string when interacting with web servers. Since we last blogged about the User-Agent string, the Internet Explorer team introduced Compatibility View and today, the Windows team is releasing the Windows 7 Beta. Each of these events has a small impact on the User-Agent string, as I will outline in this post.
The Trident/4.0 User-Agent String
In order to help users visit sites that block the “MSIE 8.0” user-agent string, IE8 will send the “MSIE 7.0” version information when viewing sites with Compatibility View enabled. As Scott described last August, a new “Trident” token in the User-Agent string allows your code to detect Internet Explorer 8 clients even when they are using the Compatibility View feature.
IE8 on Windows Vista (Compatibility View)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0)
IE8 on Windows Vista
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0)
As noted in the Best Practices for detecting the IE version, we recommend that web developers do not block access to content based on the user-agent string of the browser. If you must offer different content to different versions of the browser due to improved capabilities, you should ensure that future versions of the browser are not blocked.
Serving content based solely on the user-agent string is often an unreliable way to detect the full capabilities of the browser, because the user might have adjusted some settings, such as disabling script or extensions.
The Windows 7 User-Agent String
On Windows 7, IE8 will send the User-Agent string with the new Windows NT version token.
IE8 on Windows 7
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)
(If you’re curious about why Windows 7 uses the version number “6.1”: the short answer is that it improves compatibility, and the longer answer can be found over on the Windows Team Blog.)
Nevertheless, the “Windows NT 6.1” version token may still result in problems for a very small number of websites that check the operating system version. Such websites may show error messages or otherwise interrupt visitors who are running Internet Explorer 8 on Windows 7. The Compatibility View button will not resolve this problem for such sites, because the Compatibility View button only changes the Internet Explorer version number, leaving the Windows version number intact.
In order for IE8 users on Windows 7 to visit websites which block the “Windows NT 6.1” version string, a registry override must be set to temporarily change the reported Windows version number. If you encounter any websites that block Windows 7 visitors, please submit a bug report on Connect or provide the URL of the site in the comments below.
Detecting 64-bit Internet Explorer
As machines with more than 4 gigabytes of RAM become more common, more and more users are running 64-bit versions of Windows. For compatibility with 3rd party add-ons, the 32-bit edition of Internet Explorer remains the default on 64-bit systems. However, in some cases it can be useful for websites to recognize when users are visiting using 64-bit systems—for instance, a site may want to know whether to offer a 64-bit executable download.
Tokens in the User-Agent string will enable you to determine whether or not the user is running a 64-bit version of Windows, and whether they are running the 64-bit edition of Internet Explorer.
64-bit IE on 64-bit Windows:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Win64; x64; Trident/4.0)
32-bit IE on 64-bit Windows:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0)
Incidentally, WOW64 stands for “Windows on Windows 64-bit.”
Extending the User-Agent String
As described in the MSDN article Understanding User-Agent Strings, it is possible for users or applications to add new tokens to the User-Agent string by setting registry keys. We strongly encourage discretion in adding additional tokens, as the network overhead can become measurable as the string grows. Remember, the User-Agent string is sent in the headers for every HTTP/HTTPS request from the browser (and applications based on the IE Web Browser Control), so if you must add a token, please keep it as short as possible. We have also encountered some websites that do not function if the user-agent string is unusually long (for instance, over 128 characters).
You can check the User-Agent string your browser is currently sending here.
Thanks!
Eric Lawrence
Program Manager
Update 12:37: correcting formating of titles in post.
Comments
Anonymous
January 09, 2009
PingBack from http://www.codedstyle.com/the-internet-explorer-8-user-agent-string-updated-edition/Anonymous
January 09, 2009
I don't see anything wrong with this, though undoubtedly there will be a lot of people who will spam the comments with SVG again.Anonymous
January 09, 2009
The comment has been removedAnonymous
January 09, 2009
The comment has been removedAnonymous
January 09, 2009
What's the reason for "Mozilla/4.0" and the "compatible" token to be in the UA string? Why can't it just be "MSIE 8.0; Windows NT 6.0; Trident/4.0" ?Anonymous
January 09, 2009
@Ben: It goes back a looong time, to the Netscape days and everything. Vendors competed fiercely with one another, and Microsoft at some point in time added that to try to get content that was really intended for Netscape. (Netscape did similar things too, because a lot of people were only developing for a single browser, and blocking out the other one wasn't uncommon). It has nothing to do with the Mozilla you know now, if that's what you're thinking; it was simply the codename for Netscape back in the day. Eventually, that part became the de facto standard for a user agent string - I think these days, all browsers includes the Mozilla (compatible) part. It's fleshed out a bit more on http://en.wikipedia.org/wiki/User_agent. @OP: It's all well and good that we should keep the UA string short, but with so many things adding to it, it's hard... just take a look at mine: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30618; MS-RTC LM 8; OfficeLiveConnector.1.3; OfficeLivePatch.0.0) A whopping 249 characters, almost twice of the 128 characters reported to cause trouble on certain web servers! All of these are either created by default in Vista, or added by Microsoft products... Removing those placed in the registry gets me down to the 64 characters shown in the post...Anonymous
January 09, 2009
@Ben: Indeed, Michael is correct. You can use Fiddler (or the User-Agent picker addon) to see that some sites will not work correctly if the "Mozilla/4.0" and "compatible" are not present in the string.Anonymous
January 09, 2009
@Michael: I actually realize "Mozilla/4.0" in the UA string isn't related to today's Mozilla ... and it does back a long way like you said. But I don't see any reason why it needs to remain. It doesn't add any information and takes up a lot of extra bytes in bandwidth and web server log storage when considering the billions (trillions?) of IE HTTP requests made every day. @EricLaw [MSFT]: Not all browsers have "Mozilla/4.0" in their UA string. Firefox has "Mozilla/5.0" and looking at lists of common UA strings shows that some browsers (e.g. Opera) don't have any reference to "Mozilla". Wouldn't websites requiring "Mozilla" in the UA string not work correctly in these other browsers? I personally haven't heard of websites not working correctly without "Mozilla/4.0" in the UA string. Since the IE team appears to be recently focused more on how things "should be" rather than "used to be", I think removing "Mozilla/4.0" and "compatible" in IE9 should be strongly considered. I realize it's too late for IE8, but with advance notice (via this blog) of the removal of these meaningless terms, I'm sure the 0.000000001% of websites that would break without "Mozilla/4.0" in the UA string could make the necessary changes so their sites don't break.Anonymous
January 09, 2009
@Ben: I wish it were that easy. Unfortunately, the reality is that most sites detect the user-agent string via a library, and very often the library file relies on exact string matches. In many cases, the developers don't realize that they're checking the user-agent string at all, or if they do, they have no idea how it actually works under the covers. We learned this painful lesson back in the IE7 beta timeframe when we introduced the "b" in the user-agent string after the browser version number. This broke thousands of sites.Anonymous
January 09, 2009
I am quite shocked to see you still supporting customization of the UA string. What real world purpose does this serve other than acting as a very good place to store unique tracking IDs? Even 'normal' users like Michael Madsen are very easy to track because of the uniqueness of their browser UA string, even without a specific IDs.Anonymous
January 09, 2009
@EricLaw [MSFT]: I agree there are libraries, web stat analyzers and other programs containing UA string parsing code that the users aren't aware of. But I'd guess there would be much less negative impact removing "Mozilla/4.0" and "compatible" than the problems "7.0b" caused since it's somewhat common for libraries to extract the browser version number and the libraries are expecting a numeric value -- which 7.0b isn't and this old IE blog [1] explains that. Who's doing anything with "Mozilla/4.0" except basically discarding it? Like you said, making this change wouldn't be easy, but deciding to make it and announcing the change as early as possible would result in the best chance of success. [1] http://blogs.msdn.com/ie/archive/2006/02/03/524256.aspxAnonymous
January 09, 2009
@Ben: When the backward-compatibility of tens of thousands of intranet and internet web sites is involved, a guess may not be enough. For quite a while, Mozilla/5.0 was indicative of Gecko and Gecko-like engines and was used to discrimate IE/Netscape clients from the new Mozilla ones. Konqueror's KHTML started using Mozilla/5.0 and that is how WebKit and therefore Safari and Chrome inherited it. Applications delivering different code to browsers based on this token might therefore fail for any number of reasons. But most importantly, removing it from the UA string altogether is out of the question imho for one simple reason : it would break a large number of client and server libraries that extract version number, OS etc using regular expressions that assume the presence of the Mozilla/x.y pattern. And that would be a lot of grief!Anonymous
January 09, 2009
@SylvainG [MSFT]: Nobody can say how many libraries or sites are currently dependent on Mozilla/4.0 being present in the UA string. Some regular expressions may assume it's present and others may not. Of course the best test would be to remove "Mozilla/4.0" and "compatible" in a beta 1 release of IE9 just to see how much (or how little) havoc may result. Especially since browsers like Opera don't even have Mozilla in its UA string, there may be hope that the number of libraries/sites that need to adjust their regular expressions/parsers to not assume Mozilla/x.y exists would be a small enough number to go forward with leaving "Mozilla/4.0" and "compatible" out of IE9 RTM. Particularly if this change was announced very early on, I think giving people a full year (or so) to make any necessary changes would be adequately sufficient. Again, you guys might be right and this change may not be feasible. But a test/experiment in IE9 beta 1 just to gauge the degree of dependency on Mozilla/x.y would be a logical first step.Anonymous
January 09, 2009
Microsoft hat sich vor der Veröffentlichung einer Beta-Version des kommenden Internet Explorer 8 (IE8) nun doch (einigermaßen überraschend) dazu entschlossen, die ggü. IE6 und IE7 standardkompatiblere Darstellung von Webinhalten standardmäßig zu verwendeAnonymous
January 09, 2009
The comment has been removedAnonymous
January 09, 2009
The customization of user-agent by each and every program is indeed a problem and should be stopped. There should be an easy way in the IE GUI to a) block all writing to it b) wipe given strings from it. As a simple example: recently a few people reported that they were getting redirected to the wap/mobile version of Ebay and Sixt when they just wanted to access the main website. As it turned out those sites must be running some buggy software (Sixt runs Typo 3, don't know what Ebay uses. Maybe it's not the CMS, but some common library underneath) that reacts on the string "update" in the user-agent (coming from Creative AutoUpdate v1.10.10) and redirects to the wap version.Anonymous
January 10, 2009
The comment has been removedAnonymous
January 10, 2009
J'ai déjà eu l'occasion de traiter de la chaîne d'agent utilisateur d'IE 8 dans un précédent billet. Or, le blog de MSDN vient de publier un billet rapportant que cette chaîne est revue.Anonymous
January 10, 2009
I believe I asked this last year, but can anyone in the IE team link to any site or javascript library for which the removal of the Mozilla token would cause breakage? Any single site. One site. One use case. That's all I ask. Just a response that doesn't blindly invoke "backwards compatibility" as carte blanche.Anonymous
January 10, 2009
@Gyrobo - I'm sure Ted will jump in shortly to point out a site that long since died that still uses this archaic method to determine how to serve up content. I'm with you. If your production code is currently sniffing for "Mozilla/4.0" then YOU have a problem to fix, the IE Team does not need to bottle feed your bizarre condition. Oh, and just for Arieta - When will IE support SVG natively like all the other good standards based browsers? Is 8 years not enough time to read the spec?Anonymous
January 10, 2009
Why does MSIE 8 need a MSIE 7 UA? Throw in the confusion created regarding NT 6.0 and 6.1 for Vista, Server 2008 R2 and Windows 7 tokens in MSIE 8 (plus the one NT 6.1 in MSIE 7 and the NT 7.0 for Windows 7 in MSIE 8) UA that are in the wild, and you've got an awful mess. I hate to say it but at this rate MSIE UAs soon might not make any sense at all. And that will, unfortunately, lend lots of credence to those who say UAs should be irrelevant. They shouldn't and at this point in time can't be irrelevant. But with all this confusion it's hard to provide accurate UA definitions for MSIE 8.Anonymous
January 10, 2009
Any chance of getting rid of those .NET strings in the user agent? They add a lot of overhead to every single request.Anonymous
January 10, 2009
It's indeed a bit disappointing to see that Microsoft keeps hiding behind non(public)-proven backwards-compatibility-claims. Especially in areas where that stand causes interoperability issues imo Microsoft has at least a moral obligation to investigate and share those results with the public. By lack of any such public released investigation results we (the public) can only either conclude that any such premises are based on guesses or we should trust Microsoft on their nice blue eyes...Anonymous
January 10, 2009
Gee whiz, that took all of 2 minutes. First, set the header string to "MSIE 8.0; Windows NT 5.1; Trident/4.0" Visit WellsFargo bank's website and you'll almost immediately see http://www.wellsfargo.com/browser/denied_browser TurboTax's website also complains. Amazon's "Search inside this book" complains. Adobe's site forces users to manually download their products. Yahoo's homepage asks the user to get a different browser. etc. There are likely thousands of others. It's funny who quickly some folks assume that they somehow magically know more than the MS geeks who spend their entire lives thinking about web browsers.Anonymous
January 10, 2009
The comment has been removedAnonymous
January 10, 2009
I also find it ironic that this discussion on why the user agent should retain its antiquated structure is preceded by an article on the IE8 Blocker Toolkit. It's like saying, "We're giving you the option of not being affected by the changes we didn't make." Incidentally, I did try Yahoo's homepage with the user agent in Dan's comment. Hearken, friends, for lo! he is correct. HOWEVER- Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/4.0) Will fail just as well. So I guess Microsoft should think twice before starting IE9.Anonymous
January 10, 2009
> It's funny who quickly some folks assume that they somehow magically know more than the MS geeks who spend their entire lives thinking about web browsers. It's not about assuming to know more, but about determining and quantifying the underlying cause of the problems. Yes, a different UA-string will always cause problems with sites that keep on using (faulty) UA-sniffing techniques, but the question here is in how many cases this is caused by the unrecognized version number, and in how many cases only the removal of Mozilla/4.0 will actually cause problems (and other changes in the UA-string will not). Opera is actually also running into problems moving to a 2-digit major version ( http://my.opera.com/hallvors/blog/2008/12/19/10-is-the-one ) which only showes that almost any change to the UA-string will cause problems with some sites. Keeping old markers, introducing new markers and 'hacking' existing markers will only complicate issues in the future and do nothing to solve the real problem. The only way to overcome this is to standardise (between all browser-vendors), stick to this and evangalise sites that keep on breaking.Anonymous
January 11, 2009
I think that the fact that some sites don't work if you set your UA string to something random like "MSIE 8.0; Windows NT 5.1; Trident/4.0" is rather irrelevant. Of course, they don't, because the real IE has a different string. However, if the IE team was to announce they remove the "Mozilla/4.0" nonsense, I'm sure they would adapt. I don't think it's that of a big deal, to change some recognition logic. That imaginary UA value above that Dan used is very very wrong, however. If we try to parse it using the syntax for the User-Agent header, we will get:
- the "MSIE" product (no version);
- the "8.0" product (no version);
- the semicolon... which is not allowed. Whoops! Changing it to use the correct syntax (and semantics) will yield: MSIE/8.0 Windows_NT/5.1 Trident/4.0 Is that harder to parse than the current Mozilla/4.0 mess? I think you'll agree that it's not. Various third party apps and addons could then add their own tokens: MSIE/8.0 Windows_NT/5.1 Trident/4.0 MathPlayer/2.10d FDM (What's it doing here?) .NET_CLR/2.0.50727 .NET_CLR/3.0.04506.648 .NET_CLR/3.5.21022 .NET_CLR/1.1.4322 Note that the "What's it doing here" part is a valid comment. 8=] If IE was to switch to this (IMHO) saner format, the world would adapt. Then the other browsers would probably follow suit, ending this sad "let's stuff everything in a comment and prefix it with Mozilla/4.0 just in case" story. However, Microsoft is not likely to do it. It's too much pain for not enough gain. For a while every detection routine will have to support both the old and the new formats, which will undoubtedly lead to some aggravation. So I guess if MS will change their UA string, it will be only after they implement SVG (wink wink).
Anonymous
January 11, 2009
@Tino and All... "The only way to overcome this is to standardise (between all browser-vendors), stick to this and evangalise sites that keep on breaking." The problem of cruft that has built up over time in the UA string simply isn't big enough to attempt this kind of effort. (It would fail, in any event. IMHO) Sometimes all proposed "solutions" are worse than the disease. Let's not even bother to overcome this one, shall we?Anonymous
January 11, 2009
Regarding removing Mozilla/4.0 from the IE UA string, there may be more pain than gain upfront. But, over the subsequent months and years, the benefits of having a more intuitive, compact UA string will easily surpass the initial effort. Also, I think any problems caused by removing Mozilla/4.0 and the 'compatible' token at large websites or within large libraries is not a major concern since the large sites/libraries are of course going to be sure they adapt.Anonymous
January 11, 2009
.NET Asynchronous Fire and Forget With Lambdas There is never a collection of Value Objects Reading allAnonymous
January 11, 2009
IE 8 の User Agent に Trident/4.0 という String が加わり、アナウンスがあるかな？と思っていたところ。 IE Blog でア...Anonymous
January 11, 2009
.NETAsynchronousFireandForgetWithLambdasThereisneveracollectionofValueObjects...Anonymous
January 12, 2009
Riconoscere Internet Explorer 8.0Anonymous
January 15, 2009
Internet Explorer Browser User-Agent String ProblemAnonymous
January 19, 2009
The comment has been removedAnonymous
January 19, 2009
I'm not seeing the argument for the removal just some OCD fan boys complaining about trivial things because they've ran out of other complaints. It's like if you asked IE to be written in managed code. Except that that might even make some sense for improving security and extensibility in long haul.Anonymous
February 13, 2009
IE8 al momento è stato rilasciato in versione RC1. Una delle cose che preferisco del nuovo IE8 è il fattoAnonymous
February 16, 2009
We’ve said a lot about our approach to website compatibility in general and the Compatibility View featureAnonymous
February 23, 2009
Internet Explorer Browser User-Agent String ProblemAnonymous
February 24, 2009
Internet Explorer Browser User-Agent String ProblemAnonymous
March 24, 2009
IE开发团队更改了IE8的User-agent， 更改的部分信息如下： IE8onWindowsVista(CompatibilityView) Mozilla/4.0(c...Anonymous
April 14, 2009
A question I’ve been asked recently is  “How can I detect IE8 using JavaScript?”. There are severalAnonymous
April 16, 2009
2008 년 2 월에 말했던 (영어) 것처럼, Internet Explorer 8 은 웹 서버와 상호작용할 때, 업데이트된 User-Agent 문자열을 발송합니다. User-AgentAnonymous
April 17, 2009
Last week we took a look at Compatibility View as a way to retain the older rendering functionality just