User Agent Parser Guide: Decode Browser & Device Strings

How to Use the Parser

1. Auto-detect your browser

When the page loads, your current browser's UA string is automatically populated in the input box. The four result cards update instantly with browser name, OS, device type, and rendering engine.

2. Load a preset

Use the Quick Presets strip to load a well-known UA string with one click. Three categories:

• Desktop — Chrome/Windows, Chrome/macOS, Firefox, Safari, Edge, Opera, IE 11
• Mobile — iPhone Safari, Android Chrome, iPad Safari, Samsung Internet, Apple Silicon Chrome
• Bot — Googlebot, Bingbot, Twitterbot, Slackbot, curl

3. Paste any UA string

Clear the input and paste any User-Agent string — from a bug report, server log, analytics export, or a bot. The parser updates as you type, no button click needed.

4. Read the result cards

The Extracted Header Analysis panel below the cards shows architecture (64-bit, ARM 64-bit, 32-bit), your browser's current language, and the kernel platform.

5. Read the Token Breakdown

Below the input, the Token Breakdown panel splits the raw UA string into its individual components, each color-coded and labelled:

Click the Token Breakdown label to collapse/expand the panel.

6. Copy any value

Click the copy icon on any result card to copy that field's value to clipboard.

7. Re-detect your own browser

Click Detect Mine in the header to reload your current browser's UA string at any time.

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

Samsung Internet:

Mozilla/5.0 (Linux; Android 14; SM-S918B) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/23.0 Chrome/115.0.0.0 Mobile Safari/537.36

Detecting Bots and Crawlers

The tool automatically identifies common bots before attempting browser parsing — paste any of these and the Device Type card will show Bot/Crawler:

# 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 (underscores become dots)
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.

Architecture Detection

The tool extracts CPU architecture from the UA string:

Apple Silicon Macs include ARM64 in their UA. Intel Macs include x86_64. Windows 64-bit includes Win64 or WOW64.

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.