User Agent Parser Guide: Decode Browser & Device Strings

Anatomy of a User-Agent String

A modern User-Agent string is notoriously complex and historically incoherent — a result of 30 years of browser vendors spoofing each other to receive content intended for competitors. Here's a real Chrome UA on Windows:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

Breaking this down:

The "Mozilla/5.0" prefix is present in every modern browser because Netscape 2.0 introduced UA strings in 1996, and many servers checked for it to send capable browsers full-featured content. Every other browser had to include it to receive the same treatment.

Major Browsers and Their Patterns

Firefox on Windows:

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0

Safari on macOS:

Mozilla/5.0 (Macintosh; Intel Mac OS X 14_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.3 Safari/605.1.15

iPhone (Safari):

Mozilla/5.0 (iPhone; CPU iPhone OS 17_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.3 Mobile/15E148 Safari/604.1

Android (Chrome):

Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.143 Mobile Safari/537.36

Detecting Bots and Crawlers

Bot UA strings are generally more honest — they identify themselves clearly:

# Googlebot
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

# Bingbot
Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

# Twitterbot (for link previews)
Twitterbot/1.0

# Slackbot (for URL unfurling)
Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots)

# curl (common in API testing)
curl/8.1.2

Detecting bots is important for:

• Analytics (exclude bot traffic from user metrics)
• Server-side rendering decisions (bots need complete HTML, not SPA shells)
• Rate limiting (apply different limits to crawler traffic)
• Security (identify suspicious automated scanning)

However, malicious bots often spoof browser UA strings. Never use the UA string as the sole basis for security decisions.

Mobile vs Desktop Detection

The reliable mobile indicator is the Mobile token in the UA string:

Mobile Safari/604.1        # Present on iPhone and iPad (sometimes)
Mobile Safari/537.36       # Present on Android Chrome

But this is fragile. A tablet user-agent may or may not include Mobile. The most reliable approach for UI decisions:

1. UA parsing — good for server-side rendering decisions (which resources to send)
2. CSS media queries — better for responsive layout (based on actual viewport, not device)
3. navigator.userAgent in JS — same UA limitations, browser-side

For layout adaptation, CSS media queries based on viewport width are more reliable than UA detection.

OS Version Extraction

UA strings encode OS version, but the format varies:

Windows NT 10.0   # Windows 10 and Windows 11 (NT 10.0 for both)
Mac OS X 14_3     # macOS 14.3 Sonoma
Linux x86_64      # Linux (distribution usually not specified)
Android 14        # Android 14
iPhone OS 17_3    # iOS 17.3

Windows 11 returns Windows NT 10.0 — distinguishing Win 10 from Win 11 via UA is not reliably possible without additional signals.

Responsible Use of UA Data

UA strings enable useful capabilities but also raise privacy concerns:

Useful applications:

• Bug reports ("reproduces on Chrome 118 on Windows 10, not on 121")
• Analytics: browser market share, OS distribution, mobile vs desktop ratio
• Progressive enhancement: detect WebP support, detect specific CSS features
• CDN/edge decisions: serve mobile-optimized assets to mobile UA strings

Problematic applications:

• Browser fingerprinting: combining UA + screen resolution + fonts + timezone creates a near-unique identifier even without cookies. This is a privacy concern under GDPR and increasingly blocked by browsers.
• UA-based feature restriction: blocking users of minority browsers creates accessibility problems. Use feature detection instead.

For feature detection, prefer:

// Instead of UA sniffing
const isChrome = navigator.userAgent.includes('Chrome');

// Use capability detection
const supportsWebP = document.createElement('canvas')
    .toDataURL('image/webp').indexOf('data:image/webp') === 0;

Debugging Cross-Browser Issues

When a bug report says "it only happens on Chrome on iPhone," paste the user's UA string into our parser to extract the exact Chrome version, iOS version, and device type. This lets you:

1. Identify if the issue is version-specific (Chrome 119 bug, fixed in 121)
2. Identify if it's iOS-specific (WebKit rendering, not Chrome Blink)
3. Identify if it's related to the Mobile viewport
4. Search for known issues with that specific browser/OS combination

Combine with our HTTP Status Code reference when the issue involves request handling differences by browser, and our cURL Generator to reproduce the API call with the exact headers the failing client sent.