What's the fastest method, to detect User-Agent as metro UI version of internet-explorer >=10
?

- 9,876
- 17
- 64
- 96
-
please clarify the whole idea of the question and what are you trying to do also. – Joseph Jan 05 '12 at 23:38
-
1I think he's asking how to detect if your page is being served as a Metro app or in IE 10 since they both serve JavaScript/HTML/CSS – Brandon Boone Jan 06 '12 at 01:09
-
3Actually, I think msec is asking how do you detect a web request from IE10 running in "Metro mode" versus IE10 running in "Desktop mode" (they are not the same). My answer is below. – Kurt Schindler Jan 06 '12 at 16:04
-
As already mentioned, I don't think you can determine the metro UI specifically. It is however easy to use a little function [here](http://hankchizljaw.co.uk/tutorials/detect-internet-explorer-and-ie-version-with-javascript-tutorial/18/04/2012/) that you can parse the IE version with. The next step really is deciding what "features" you want to detect. Check [Modernizr](http://modernizr.com/) out, it is really nice, clean and light. I find it really useful with modern UI development. – HankChizlJaw Jun 13 '12 at 09:43
-
My particular scenario is creating a Windows equivalent to http://cubiq.org/add-to-home-screen. The UI for this obviously needs to change based on Metro vs. Desktop version of the browser. If you can identify something I can do feature detection on to make this distinction, you get the bounty :) – Robert Levy Jun 13 '12 at 13:58
-
I see where your going, you need a different popup per device. Am I on the right track there? – HankChizlJaw Jun 14 '12 at 11:36
-
kinda but not "per-device"... the user could switch between Desktop IE and Metro IE on a single device – Robert Levy Jun 14 '12 at 13:30
-
From what I can find online it looks like the user agent string is going to be the same for both metro and aero UI. I think your only option will be to use modernizr with feature detection. It's a real tricky one this is!! – HankChizlJaw Jun 14 '12 at 19:00
-
Indeed. So the question is: what "feature" do I try to detect to make this distinction? – Robert Levy Jun 14 '12 at 19:16
-
I would probably go with touch personally. Check [here](http://hankchizljaw.co.uk/tutorials/make-your-mouse-events-touch-friendly-with-jquery-tutorial/28/04/2012/) for touch detection. – HankChizlJaw Jun 14 '12 at 19:27
-
You can touch the desktop too – Robert Levy Jun 15 '12 at 11:16
-
Have a look at my answer. It actually works reliably - maybe tick it if you agree it is a better solution than the currently ticked item ;) – robocat Aug 28 '14 at 02:39
11 Answers
So, there doesn't appear to be a definitive test to identify Metro IE vs Desktop IE, but there does seem to be a few different pieces of data you can attempt to use to assume that it is Metro. Unfortunately, none of the items I have found can't be explained away by other settings. In other words, for all the "feature" tests I have found, Desktop IE could be configured in a way to trick the tests into thinking it was running on Metro.
Is ActiveX disabled (Metro doesn't allow any activex content, but desktop IE can have it set to disabled as well):
function isActivexEnabled() {
var supported = null;
try {
supported = !!new ActiveXObject("htmlfile");
} catch (e) {
supported = false;
}
return supported;
}
User Agent string check (Metro will always run in 64bit mode, but won't on a 32bit machine, and Desktop IE can be configured to run in 64bit mode as well not sure how popular either of those options will be)
function isWin64() {
return navigator.platform == "Win64";
}
Full screen check (Metro will always be in full screen mode, however Desktop IE can also run in full screen mode, but this could be used as supporting evidence of Metro mode)
function isFullScreen() {
return (window.innerWidth == screen.width &&
window.innerHeight == screen.height);
}
In short, I think you have to try to check a bunch of features, and then guess, there is no definitive way. Or you could just accept that MS doesn't want you to do this, and use feature detection for the features you want to use.
For those that want to try to provide UI to refer to the containing browser UI (to indicate how to Pin the web page for example), keep in mind that other Metro apps can embed the IE10 Metro browser as a control, so even if you could identify the browser as Metro vs desktop, the UI might not be where you'd attempt to refer to it, so this can end up being a pretty tricky situation to get right 100% of the time. So either, don't try, or you could attempt the other detection techniques and accept that there are use cases that you could be displaying the wrong UI.

- 2,317
- 2
- 20
- 26
-
`window.innerWidth == screen.width` cannot be used as a test for IE metro. 1) In Desktop view, the user can press F11 to go full-screen, and the screen values are then the same as in Metro. 2) because window.innerWidth != screen.width when using snap/split-screen view (also window.screenX != 0 if IE is snapped to the right). – robocat Oct 25 '12 at 20:50
-
Also neither `window.innerHeight` nor `window.innerWidth` may be compared to screen height/width, because they are not measured in physical pixels. The innerHeight/innerWidth values are inversely proportional to the window zoom. – robocat Oct 25 '12 at 21:23
-
@robocat, agreed the inerWidth and innerHeight checks are flaky, but used with the other checks they can be used potentially to increase the confidence that IE is in Metro mode, since MS has been kind enough to not make available a true test for Metro mode. None of these checks on their own mean that IE is in Metro mode, as desktop IE can be configured to trick each of these checks, but it is less likely that desktop IE is configured to trick all of the checks. Ideally, MS would provide a real way to test or identify Metro mode. – Bert Lamb Oct 26 '12 at 18:50
-
1`document.documentElement.clientWidth == screen.width` is better to use if sniffing for width because in Metro the clientWidth value doesn't change with zoom due to a bug in Metro (tested on IE10.0.9200.16466 on Windows 8). The value changes in Desktop depending on zoom (correct behaviour). However sniff won't correctly work if user presses F11 on desktop IE10. Try it out: http://jsbin.com/iqibik/2 (must use jsbin, not jsfiddle in iframe, when testing window/document variables!) – robocat Jan 23 '13 at 03:33
-
2I've been using this method for some time successfully, but I found out that including the full screen test is relatively problematic. First of all, it's not working at all for IE11, since IE11 reports a different height (I think that the height of the address bar is now included in the screen size, while in IE10 was not). But more importantly it doesn't work when IE is snapped, which is quite common. Removing the full screen test makes the detection less secure, so be careful when using it. – kkara Nov 04 '13 at 14:36
-
Height sniff broken in IE11 due to 15px black bar at bottom in IE11 Metro. Width sniff broken if snapped (as noticed by kkara). Width/Height sniffs can be broken if F11 fullscreen or touch-zoom used. Test using http://jsbin.com/uluFeKEW/3 – robocat Nov 18 '13 at 05:23
-
http://jsbin.com/uluFeKEW/5 - use instead of link above - improved comments and fixed ActiveX sniff. – robocat Nov 18 '13 at 05:51
I don't believe there is a way to determine if a request is coming from the Metro version of IE10 versus the regular desktop mode version. Metro IE has no unique HTTP headers or user-agent string to identify it by.
Internet Explorer 10 User Agent Strings On Windows 8 64bit
Metro IE10 is a 64-bit application, so you'll see "Win64" in the user-agent string. Regular desktop IE10, by default, is 32-bit and will show "WOW64". You could sort-of make an educated guess based on this, but you would falsely identify anyone who chose to run the 64-bit version of IE10 in desktop mode. As you can see from that chart, the user-agent strings are identical. [edit: as noted in the comments, this won't work for 32-bit PCs.]
I could see why you may want to detect Metro IE, but this type of "browser sniffing" is generally discouraged because it's so cumbersome and error-prone. It would be best to feature test for certain browser functionality that you require using something like Modernizr, if you can.

- 21,037
- 4
- 43
- 48
-
1+1 - Interesting to know there's a Metro version of IE10 and a normal desktop version. I was under the impression that Metro was just another interface for rendering web-content. – Brandon Boone Jan 10 '12 at 02:20
-
On Consumer Preview, is anyone else seeing the UA for 64-bit Classic IE10 as "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; .NET4.0E; .NET4.0C; Media Center PC 6.0)"? Note the "WOW64" instead of "Win64". – Bullines Apr 02 '12 at 00:35
-
The problem for me is that IE10 Metro doesn't allow you to test for some of the features that differentiate it from non-Metro, notably that ActiveX extensions will never be allowed so you shouldn't bother trying to put up UI to offer to install them. I wrote a blog post about this. http://blog.bertlamb.com/2012/06/07/why-internet-explorer-10-metro-should-have-a-different-user-agent/ – Bert Lamb Jun 08 '12 at 12:56
-
1This solution won't work for 32-bit PCs where "WOW64" and "Win64" won't be present in the desktop UA either – Robert Levy Jun 12 '12 at 18:28
-
Modernizr is not working for us in detecting IE10 in metro mode. Apparently Modernizr only detects WebKit compatible touch, see https://github.com/Modernizr/Modernizr/issues/548 – Jeff Atwood Nov 20 '12 at 21:20
-
1Neither WOW64 nor Win64 are present on the devices where you're actually likely to care about which version you're running - the Surface and other ARM devices. – mjaggard Feb 21 '13 at 10:26
Thanks John Rajakumar and Alexis Pigeon. I was able to use your Metro IE check as the basis to load a separate CSS style sheet for Metro tablets (MS Surface). To add a bit more certainty in my mind, I used cssuseragent to detect IE10 first, and then combined both tests in a final yepnope test.
var IEmetrotest = ((cssua.userAgent.ie > 9) && (metrotest()));
yepnope({
test: IEmetrotest,
yep : ['ie_metro.css']
});
Tested it in Browserstack and it's working as expected. (I would have up-ticked you, but don't have enough points yet.)
// Minor revisions to isBrowserSupportPlugin() previously posted
// Renamed function to metrotest() and inverted the returned value.
var errorName = null;
function metrotest() {
var supported = null;
try {
new ActiveXObject("");
}
catch (e) {
// FF has ReferenceError here
errorName = e.name;
}
try {
supported = !!new ActiveXObject("htmlfile");
} catch (e) {
supported = false;
}
if(errorName != 'ReferenceError' && supported==false){
supported = false;
}else{
supported =true;
}
return !supported;
}

- 340
- 5
- 15
METRO IE never supports ActiveX or any plugin objects. Based on that the following script is tested & working fine.
//---------------------------Metro IE check-------------------------
var errorName = null;
function isBrowserSupportPlugin() {
var supported = null;
try {
new ActiveXObject("");
}
catch (e) {
// FF has ReferenceError here
errorName = e.name;
}
try {
supported = !!new ActiveXObject("htmlfile");
} catch (e) {
supported = false;
}
if(errorName != 'ReferenceError' && supported==false){
supported = false;
}else{
supported =true;
}
return supported;
}
//----------------------------------------------------------------

- 7,423
- 11
- 39
- 44

- 11
- 1
Reliable Modern/Metro detection!
I have found a way to detect Modern versus Desktop which you can try here: http://jsbin.com/genac/2 (edit using Chrome or Firefox not IE http://jsbin.com/genac/2/edit).
It seems to be a fairly robust detection because:
- it works even if pinch-zoomed
- it works even if two windows snapped side by side on Modern(Metro)
- it works even if page zoomed using ctrl-+ and ctrl--
- it works even if desktop is fullscreen using F11 key on Desktop (autohiding taskbar)
The trick is that the page scrollbars on Modern do not make the client window size smaller (they appear above the page), but the page scrollbars on Desktop do affect client window size (usable window size is smaller).
The main downside is that the test requires that you have a scrollbar on the page to sniff the difference. Does the same difference in scrollbars happen in an iframe or autoscrollable div?
Edit: I would test that the browser is IE11 before using this code, because Windows 10 doesn't have Metro/Modern and Edge acts slightly differently.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=EDGE" />
<title>Metro width detector - robocat</title>
<script>
function show() {
var div = document.createElement('div');
var s = [];
s.push('IS METRO? ' + ((tester.offsetWidth == window.outerWidth) ? 'YES' : 'NO'));
s.push('document.documentElement.clientWidth: ' + document.documentElement.clientWidth);
s.push('document.documentElement.offsetWidth: ' + document.documentElement.offsetWidth);
s.push('window.innerWidth: ' + window.innerWidth);
s.push('window.outerWidth: ' + window.outerWidth);
s.push('screen.width: ' + screen.width);
s.push('screen.availWidth: ' + screen.availWidth);
s.push('document.documentElement.getBoundingClientRect().width: ' + document.documentElement.getBoundingClientRect().width);
s.push('tester.offsetWidth: ' + tester.offsetWidth);
div.innerHTML = s.join('<br>');
document.body.insertBefore(div, document.body.firstChild);
}
window.onresize = function() {
show();
}
</script>
</head>
<body onload="show()" style="margin:0">
<div id="tester" style="position:absolute;left:0;right:0;"></div>
<div style="height:10000px;width:10px;background-color:blue;"></div>
</body>
</html>
You can look at page/window dimensions using: http://jsbin.com/AbimiQup/10 (edit using Chrome or Firefox not IE http://jsbin.com/AbimiQup/10/edit)
PS: There might be some way to sniff the scrollbar difference from the runtimeStyle for body or document.documentElement because maybe -ms-overflow-style: -ms-autohiding-scrollbar is used (e.g. document.documentElement.runtimeStyle.msOverflowStyle) but I couldn't find anything.
PPS: The ActiveX method given in other answers is not particularly reliable (e.g. users can disable) and it causes UI uglyness because in IE11 it shows a "ActiveX" icon next to the url.

- 5,293
- 48
- 65
-
Notes to self: // MS tablet detection: look at user agent for ARM; and Touch;? What about Pro tablet? "Windows Phone" for Windows Phone? Note "Tablet PC" was used for IE8/IE9? // IE9 64-bit is not same as 32-bit: "IE 9 64-bit is using an older, slower JavaScript engine, while IE 9 32-bit was using the newer, more efficient Chakra JIT. Internet Explorer 9 64-bit is an absolute dog when it comes to JavaScript performance." // RELIABLE METRO VERSUS DESKTOP TEST?!: scrollbar width zero on body - outer width minus inner width. In IE10 Metro scrollbars opaquely layer over top and are zero width. – robocat Feb 20 '14 at 01:55
Here is a consistent method, with no ActiveX check dependency, as tested in IE10 and IE11 specifically.
if (window.screenY === 0 && (window.innerHeight+1) !== window.outerHeight){ //IE metro/modern UI }
The first rule detect IE's full screen or modern view (which may or can also be true on IEMobile). Maximized mode being historically always associated with positive or negative screenX and screenY.
And the last rule excludes [Full screen/F11] mode, which for some reason constantly shows a 1px discrepancy between outerHeight
and innerHeight
as tested on IE10/Win8 and IE11/Win8.1
PS: I voluntarily do not declare window.screenX === 0
. Only use screenY
in order to cover Modern/Metro in snap-mode with a window context snapped to the right (i.e. screenX !== 0).

- 5,177
- 3
- 31
- 56
-
This is excellent. I've tested this extensively on IE 10+11, metro+desktop+fullscreen. I'd add that you need to check that you're running IE (perhaps with the UA string), since other browsers can pass both of these tests in some circumstances (e.g. Chrome in fullscreen). – aaaidan Dec 11 '14 at 03:39
-
-
@aaaidan I know! I tested extensively :) Indeed IE detection is a pre-requisite. The best option there, might be `!!window.StyleMedia` at this point, given the radical user-agent changes between IE 10, 11 and upcoming IE12. I'll eventually update my answer accordingly. – hexalys Dec 11 '14 at 23:23
I tested the following and it works, a jsfiddle showing this can be found here.
This is a bit of long shot, but seems quite a sensible solution:
Why not check whether the browser is full screen1 and depending on that call the fullscreen one metro. I have windows 8 running on my computer at work, so I will try to check tomorrow whether there are any GUI's still around (don't think I remember any) and if so, you would need to manually subtract them. True, it's not the most beautiful solution, but as far as I know there won't be any 'beautiful' solution and this could prove to be a pretty solid hack, as the GUI of metro IE can't be changed with any toolbars or similar software (as far as I know). True, it could lead to a misidentification of the desktop IE, but even that is within reason, as a fullscreen desktop IE will still give a similar experience.
1 Giving something along the lines of:
if(window.innerWidth == screen.width && window.innerHeight == screen.height) {
// metro
} else {
// desktop
}

- 26,123
- 9
- 51
- 114
-
Just tested and this *does* identify metro. Try opening http://fiddle.jshell.net/JbGek/2/show/light/ in metro and in desktop – David Mulder Jun 19 '12 at 14:52
-
Hmm...you're right, that does seem to work, not sure why it didn't on my test page, possibly because I was running in an IE compatibility mode. – Bert Lamb Jun 19 '12 at 15:46
-
In Firefox, the innerHeight of full-screen is one pixel less than screen.height, presumably because the top line of pixels activates the toolbar – Webveloper Aug 07 '12 at 22:07
-
1interestingly enough opening that in both desktop and metro, both reported "Desktop", maximizing desktop by F11 reported "Metro", so it is unfortunately not reliable... it happens with more than 1 monitor of different sizes! – jJ' Jan 31 '13 at 17:35
-
That's odd, I tested this with the release candidate back then and on it it identified both correctly in the fiddle. I guess some additional tweaking could be necessary as far as alternative settings in metro, but at least it get's you farther than saying nothing is possible (as at least this does work in certain situations) and the misidentification whilst in fullscreen mode on the desktop I already mentioned in my answer yes. (which is within reason, because in that case you probably want to show a metro like interface either way) – David Mulder Feb 10 '13 at 22:38
-
Couldn't _any_ browser in fullscreen mode also pass this test? Might want to beef this up with some other tests, including a IE UA test. – aaaidan Dec 11 '14 at 03:44
By the sounds of it you are looking to do something along the lines of Pinning a site to the start screen within Metro. To do that you can check if a site can be pinned by using this code that was brought in with IE9 and can be done by doing something like this...
function doChecks_Browser() {
// full pin abilities == can pin && Win7+
if (pinnedSiteDetection.hasFullPinAbilityBrowser)
}
More info on that here.
From this this post on MSDN...
Windows 8 Release Preview implements pinned sites by using tiles on the Start screen. When a user clicks the tile of a pinned site, the site opens in Windows Internet Explorer 10 Release Preview in the Windows Metro style UI environment.
Hope that helps!

- 334
- 4
- 6
-
Kinda… I want to prompt the user with visual indication of *how* to pin like http://cubiq.org/add-to-home-screen does on iOS. This UI needs to change based on whether I'm in Desktop IE or Metro IE. – Robert Levy Jun 14 '12 at 19:24
-
Ah right ok. Well in this [link] (http://msdn.microsoft.com/en-us/library/ie/gg491729(v=vs.85).aspx#drag) it shows you how to do a popup that will tell the user to drag the site icon into the taskbar. Not sure what the equivalent would be or if this works in Metro on Windows 8 but worth a try. – tcmorris Jun 14 '12 at 19:29
It tried out the code below and it seems to work.
It doesn't catch if the user goes InternetOptions->CustomLevel->ScriptActivexControlsMarkedSafeForScripting=false on you though. If the user does this the code believes it's a Metro/Modern.
Presently I see no way around this by checking OS, FullScreen and whatnot.
isWinModern checks for Metro/Modern.
isWinDesktop checks for Windows as Desktop (=non modern in this case)
The code below is not guaranteed to work.
function isWin8Modern() {
if (!!window.ActiveXObject) {
try {
!!new window.ActiveXObject('htmlfile');
return false;
} catch (exc) {
return true;
}
} else {
return false;
}
}
function isWinDesktop() {
if (window.ActiveXObject) {
try {
new window.ActiveXObject('htmlfile');
return true;
} catch (exc) {
return false;
}
} else {
return false;
}
}

- 7,195
- 6
- 56
- 107
var _ua = window.navigator.userAgent;
var isIDevice = (/iphone|ipod|ipad/i).test(_ua);
var isMobileChrome = (_ua.indexOf('Android') > -1 && (/Chrome\/[.0-9]*/).test(_ua) && _ua.indexOf("Version") == -1);
var isMobileIE = _ua.indexOf('Windows Phone') > -1;
function isActivexEnabled()
{
var supported = null;
try
{
supported = !!new ActiveXObject("htmlfile");
}
catch (e)
{
supported = false;
}
return supported;
}
if (!isIDevice && !isMobileChrome && !isMobileIE && _ua.toLowerCase().indexOf("wow") == -1 && !isActivexEnabled())
{
//IE Metro UI
}
This Work For Me..

- 1
- 2
I spent some time on this and figured out a way. I thought about what is missing from IE10 Metro and only one thing that is documented isn't supported in the Metro UI. The developer tools. Well, those tools have objects in the window object. One of these is "__IE_DEVTOOLBAR_CONSOLE_COMMAND_LINE".
If you do something like
if (window.__IE_DEVTOOLBAR_CONSOLE_COMMAND_LINE)
{
// In IE 10 Standard UI
}
else
{
// In IE 10 Metro UI
}
I've tested it in a few different environments and it appears to work most places. The only hiccup I can think of is if the developer tools were somehow disabled on the user's browser.
-
1You shouldn't detect for window.__IE_DEVTOOLBAR_CONSOLE_COMMAND_LINE. That is only added once F12 (the developer toolbar) is opened so really it's just testing if F12 has been opened. You would also be relying on an implementation detail of F12 which can change as it is not a standard API. – Andy Mar 01 '12 at 20:57
-
FYI: In IE11, `window.__IE_DEVTOOLBAR_CONSOLE_COMMAND_LINE` appears to no longer exist. Instead there is `window.__BROWSERTOOLS_CONSOLE` , `window.__BROWSERTOOLS_CONSOLE_BREAKMODE_INVOKER` , and `window.__BROWSERTOOLS_DOMEXPLORER_ADDED` – robocat Nov 18 '13 at 23:59