Browser Detection with JavaScript

If you really must do it, detecting what browser someone is using is easy with JavaScript.

JavaScript has a standard object called navigator that contains data about the browser being used.

The navigator object has a lot of properties, but the .userAgent property — a string that contains data about the browser, operating system, and more– is all we’ll need.

If we wanted to show the value of navigator.userAgent, we could do one of the following:

Alert

// Display in an alert box
alert(navigator.userAgent);

Value of navigator.userAgent in Firefox 30 on Windows 7

Document.write

// Write it in the HTML document
document.write(navigator.userAgent); 

console.log()

// Display it in the browser's developer tool
// This is ideal
// Use console.log() when you're developing/experimenting JavaScript
console.log(navigator.userAgent);

If I was using Internet Explorer 11 on Windows 7, the output will be:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MASM; .NET4.0C; .NET4.0E; rv:11.0) like Gecko

As you can see, the issue with navigator.userAgent is that it’s one giant string, and it’s not very human-readable either.

So if I wanted to work with the information, or show it to the user, I’ll need to parse the string first.

The problem is I’m extremely and embarrassingly incompetent at regex (among many other things), so I’m glad the Detect.js JavaScript library by Darcy Clarke exists.

Detect.js will be able to parse the string value into a human-readable and operable JavaScript object.

To display the browser name, browser version and operating system in our console, this is how we could do it:

// Create 'user' object that will contain Detect.js stuff
// Call detect.parse() with navigator.userAgent as the argument
var user = detect.parse(navigator.userAgent);

// Display some property values in my browser's dev tools console
console.log(
 user.browser.family
 user.browser.version
 user.os.name
);

In Firebug, this is what I’ll see:

Firefox 30 Windows 7

And this is what I’ll see in Chrome DevTools using the same machine:

Chrome 35 Windows 7

To target a specific browser, you can use conditional statements.

For instance, if you want to target just desktop Safari, you could do this:

if (user.browser.family === 'Safari') {
 alert('You\'re using the Safari browser'); 
}

Here’s a table of all the parsed properties:

Note: If any property can’t be parsed, its value will be null or undefined. If you’re going to show the information to your users, you should have conditional statements in place for null and undefined.

Why you shouldn’t use JavaScript browser detection

I do not recommend using JavaScript browser detection.

And you should never, ever use the techniques I’ve described for anything that’s mission-critical.

Why?

JavaScript browser detection is not reliable

JavaScript can be turned off by the user.

Also, there are a lot of browsers and browser-versions out there — and there will be more in the future — which makes browser detection impractical and unmaintainable as part of an always-up-to-date codebase.

Feature detection is a better option

If you’re using JavaScript browser detection for the purpose of checking whether or not the user has a certain browser capability — like a new HTML5 API such as WebRTC or Canvas or whatever — it’s much better to determine in real-time if that capability is available.

I’ll use WebRTC to demonstrate my point.

According to caniuse.com, this is the browser support status of WebRTC:

Source: caniuse.com

In the browser support table above, red is incompatible and green is compatible.

If we were to use browser detection to determine if the client is able to use WebRTC, it would require a ton of conditional statements. And every time a new browser version is launched, we’d have to update our code.

Plus, we’re only talking about the thirteen browsers listed in the support table; we’re not yet accounting for the other web browsers currently in the market as well as the browsers that haven’t been created yet.

And I should note that using some sort of browser-support reference table is not reliable either. It’s updated and maintained by people just like you and me (though some are automated using a feature-detection script).

And just like you and me, life sometimes gets in the way of maintaining our work.

Instead, it’s a good idea to check in real-time if the feature we want to utilize is available in the client’s browser. This technique is called feature detection.

How can we detect if the WebRTC feature is available in the browser?

Well, we know that a WebRTC-capable browser should have the getUserMedia() function, so we could check to see if we can invoke it.

The code below tests the WebRTC capability of the client and pops out an alert box if the feature is available. This is borrowed and adapted from MDN:

// hasWebRTC is undefined
// if .getUserMedia() (and its variants) is not available
var hasWebRTC = navigator.getUserMedia ||
 navigator.webkitGetUserMedia ||
 navigator.mozGetUserMedia ||
 navigator.msGetUserMedia;

if (hasWebRTC) {
 alert('This browser is fully or partially WebRTC-capable');
}

Use the Modernizr JavaScript library for more sophisticated browser feature-detection.

The only reason I can think of for JavaScript browser detection is inessential progressive enhancement.

For instance, if I wanted to slightly add to the experience of people that use a specific browser, then JavaScript browser detection is a very quick (and very dirty) solution.

Related Content

• Responsive Full Background Image Using CSS
• 7 Crazy Tips That Will Help You Become a Better Coder
• 5 Good Habits That Will Make You a Better Coder