There are many reasons why you might want to distinguish mobile from desktop browsers or why you would NOT want to make this distinction. Someone will tell you that you should not care, someone will tell you that you can’t avoid considering that mobile devices are not desktop computers.

The W3C has started an initiative called MWI that has the “One Web” as part of its scope.

On the other side you might want to have a single URL (example.com) and then provide 2 or more different presentations and contents. There are some valid reasons to provide different contents to different browsers and there are some valid reasons to provide the same contents independently from the device or medium. We will not go down this way, but will try to list a few common techniques to be able to distinguish a mobile browser from a desktop browser. If you don’t care or if you are willing to actually provide the very same experience, then this FAQ entry is not for you.

Probably the most comprehensive solution is to use WURFL plus the web patch. I suggest that you also read about the patch file. WURFL has a very useful capability called is_wireless_device that will tell you if the device that is visiting your site is a mobile device or not.

Mobile devices will need to access the Internet using a mobile operator. You might maintain an updated list of the operators’ IP classes and subclasses.
The only problem with this solution is that operators might change their IP’s and if you want to do something on global scale, keeping the list up-to-date will take a long time.

Nothing prevents a user on-the-move to use his mobile device or PCMCIA card to access the Internet. This user will also come from a mobile operator’s IP. This means that you should keep a separate list of IP’s used by WAP gateways and some operators might use the same groups of IP’s both WAP gateways and “web” users.

Modern mobile devices might access the Internet without using a WAP gateway. The WAP 2 protocol does NOT require the use of a WAP gateway.

Users with advanced mobile devices might use the mobile operator’s network in some occasions and a Wi-Fi provider in some other occasions. The device would still be a mobile device. An example is Nokia’s E61.

Here is the GURFL CSV file, which is a common effort by the whirlymobile people (with help from the wmlprogramming community) to try to list IP classes of mobile operators.

Checking HTTP headers is another possible solution. WAP devices will most likely advertise the support for WAP markups (WML and XHTML). See also What's with the HTTP server MIME types?

Another useful header is x-wap-profile. The OMA suggests that mobile browsers support this header and provide a UAProf. This is not a requirement, though and some mobile browsers might not follow the rule, especially devices that are sold by operators or manufacturers that are not part of OMA (for example Verizon Wireless).

Some browsers might try to disguise as web browsers even if they are running on a mobile device because they implement some special feature to adapt the content to the small screen. Sometimes these browsers might even be able to do a better job than you could because they will know the hardware and plug-ins installed on the device.

Luca Passani has released the Switcher,a servlet that can programmatically detect if an HTTP request comes from a mobile device. The Switcher applies a set of heuristics which are most likely to succeed in detecting mobile devices.

Providing different URL‘s will still lead some visitors directly on the appropriate version. Providing different host names such as mobile.example.com, wap.example.com and www.example.com is another alternative.

Probably the best solution is to do a combination, do some tests and identify a good rule that covers most cases. Which path and combination is up to you, the tools you have available and the time you can dedicate to this.

More and more hybrid devices are surfacing the market. Sometimes it could be good to make the decision that you think is best for the visitor and then provide a way to jump to the other version.