Detecting Mobile Devices — Don’t Bother

Image of mobile phone showing this site.Since I started working on the web (and was slowly coaxed to the world of Netscape from Mosaic and HotJava), clients have asked me to find ways to adjust how a page behaves based on what browser the end user has. Before campaigns like the Web Standards Project (WaSP) took hold and slowly convinced web developers, and by extension clients, that the right approach is to build for standards first, web developers struggled with everything from clunky JavaScript user agent sniffers to server-side components like the browscap.ini file for IIS. These all took time to maintain and were never 100% effective.

I am thrilled we’ve gotten to the point in the web where progressive enhancement is in vogue, finally falling in line with our own practices of the last decade or so. With the advent of mobile devices and plunging screen resolutions, we have support in the form of CSS media queries to adapt a single page to multiple devices, now referred to as responsive web design. Yes, we are still struggling with the best practices and design differences (such as forgetting print styles), but the overall concept is solid. No longer must you code a text-only page, a mobile page, a printable page, and a regular page (or the templates for each if you are using a web content management system). You can build one page and let it handle all those scenarios.

Except sometimes you find yourself in a situation where you have been asked to develop a different experience for a mobile user that lies outside the ideal of responsive sites. That different experience can be as simple as sending a user to a different page on the site if he or she is surfing on a mobile device. All those years of progress are swept away in one moment and we are back to struggling with user agents. I’d like to provide a little context on why such a simple-sounding request can be such an effort to implement.


If we fall back to user agent sniffing (reading the browser’s User Agent as it reports to the server), then we have an uphill battle. Just finding a comprehensive list is an effort. One site lists hundreds of user agent strings, and there is even a SourceForge project dedicated to staying on top of them all. When you consider how many different phones and browsers there are, and how often new ones come out (such as Amazon Silk), your clients need to understand that this approach is doomed to failure without ongoing updates (and fees).

If all you do is follow Google’s advice on its Webmaster Central Blog to simply look for the word “mobile” in the string, you’ll fail immediately — user agents on Android devices do not need to conform (and often don’t) to what Google says you will find. Opera doesn’t include “mobile” in its user agent (Opera/9.80 (Android 2.3.3; Linux; Opera Mobi/ADR-1109081720; U; en) Presto/2.8.149 Version/11.10), and the browser Dolphin doesn’t even include its name in the user agent string (Mozilla/5.0 (Linux; U; Android 2.3.3; en-us; PC36100 Build/GRI40) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 ).

You can take the inverse approach and instead detect for desktop browsers. It’s smart and simple as far as user agent sniffing goes, but still falls prey to the same problem of the constantly changing landscape of browsers. Given that the next version of Windows is intended to quickly switch its interface back and forth between desktop and mobile (keyboard and touch), unless the user agent for all the browsers installed on that device change as the user changes the device orientation, that technique is also doomed.

Serving different content based on screen resolution gets you around the user agent sniffing, but isn’t any more effective. With tablets approaching desktop screen resolution, and smartphone resolution approaching tablet resolution, there is no clear method for determining what kind of device a user has. An iPhone 4S held horizontally has 960 pixels of resolution and the Dell Streak tablet has 800 pixels (to clarify, the smaller device has more pixels, which is contrary to what most might expect). If you want a tablet to have a different experience than a phone, then serving it based on screen resolution won’t do it. As it is, the resolution of many tablets matches that of my netbook (1,024 x 600), which is definitely not the same type of device (it has a keyboard, for example).

What To Do?

Try to solve the objective earlier in the overall process — generate a different URL for mobile, embed it in different QR codes, look into feature detection, look at using CSS media queries to display or hide alternate content, and so on. Every case may require a different solution, but falling back to methods that were never reliable certainly isn’t the right default approach.

Update: November 13, 2013

I’m just going to leave this link here for you to read at your leisure: Internet Explorer 11’s Many User-Agent Strings

Update: February 10, 2015

PPK has shown us that while we may think that Chrome reflects just one browser on a given platform, on Android Chrome represents eleven different browsers. With as many different sets of quirks.



Detecting is fine, but its not flawless, and some people actaully resent being redirected without the option to select thier user experience. I agree with the title of your article.

I don't think that there is an officially accepted best practice. Given that most detection is done with javascript, relying on it and its presence includes risk.

For that reason, I recommend using a lo-fi solution which gives the user the option to select their experience. I think giveing users options is important and I would rather do that than maintain and constantly test my detection logic.

Simply provide links to "Mobile Version" and "Tablet Version" of the web site.

Then take it futher and have unique links for each OS so you would have:
"CHOOSE YOUR MOBILE EXPERIENCE: Android | Apple | Black Berry | Mobile Site

–Android give you an option to download an application for "Smartphone | Tablet"
–Applie gives option for "iPhone | iPad"
—Backberry gives a link to download a reader app
–The Mobile Site would be a version of the site sized for mobile

Something to consider is that all manufacturers provide Official user interface (UI) and user experience (UX) guidelines Many of the guidelines focus on native application development, but we can apply most parts of them to mobile web design too. The key is to try to provide the best possible experience on each platform. Do not deliver an iPhone experience to a BlackBerry user. Every platform has its own UI and usability guidelines that every user is expecting on your app.

I found one site that is following this logic: Wall Street Journal

There are other strategies of course, but this is a lowest common denominator.



Designers and developers often forget that the users themselves have a certain expectation based on the experiences of their own devices. User who have spent their time surfing on a 2 year old BlackBerry will not expect a keen viewing experience on many websites. Trying to detect and manage a market that changes as fast as the consumer device space is a Herculean task-it also does not help the web standards cause.


Well if anybody DOES decide to redirect a mobile browser/device, you can always use this:

justindocanto; . Permalink

Justin, the whole point of this post is to demonstrate that a browser sniffer isn't a sustainable long-term solution. If someone reading this implements it, even if there are no missed browsers today, is the client willing to pay to have the developer go back and replace the code each time a new browser comes out? And what's the guarantee you'll even be maintaining it in a year or two so that developer can get a current browser sniffer?

Also, how does your script detect IE10 in metro mode versus desktop mode?


Hi. I just came across this searching for topic related to the business I'm working with.

We have made an automated targeting platform that automatically redirects users to different locations based on what device type and OS they use, there location (currently country, region and city in the works) and more.

This solved the problem of having to use multiple URL's or QR Codes for different devices or platforms. It's requiring no technical knowledge or integration – and we keep the detection up to date. Give it a try at

Any feedback on the service from professionals like you would be very much appreciadet.

Morten L. Jørgensen

In response to Morten. Reply

Morten, I feel like you're trying to solve a different problem. Your site doesn't seem to do anything different based on my device.

How often do you update the list of user agents? How are you handling for the IE10 user agent between two different surfing modes (desktop and Metro)? Do you provide screen resolution and viewport information as part of this service?


What about using a web service like Device Atlas?

Yes it costs, but totally negates the problem of user-agent updates and claims to be 99% accurate.


In response to John Coombes. Reply

That's a good question. I don't know DeviceAtlas, but I did take a quick look at their information for a Microsoft Surface – Windows 8 Pro, an example of one that is confounding authors since it doesn't indicate in the DOM or UA which mode it is in. That page shows that perhaps 75% of the data is missing for that one device, in my opinion negating any 99% accuracy claim. So, in short, no I would not use it.


Developers may also want to consider WURFL ( for an easy way to have great device detection and form factor detection.

Anonymous; . Permalink
In response to Anonymous. Reply

Which version, the opensource (wurfl.js) one or the licensed (WURFL, which I understand is about $1,500/yr)?

Now the question I keep asking but nobody pimping a library seems willing or able to answer, can it tell me when a user with IE10 or greater is visiting in desktop or "metro" mode?


Is it possible to do something like:
If mobile device and screensize above 600 on the short side
then force device in landscape mode and display and fit to screen.
And how would I go about it?

In response to Jonas. Reply


Media queries will “detect” the screen size for you. Knowing whether or not it’s a “mobile” device? See my post above. As for forcing the device into landscape mode from a browser, I hope that is not possible (I am not aware of an API for that). Finally, use media queries to adapt the layout to the screen.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>