User Agent Parser
Extract browser, engine, OS, and device info from any user-agent string.
Why Chrome Calls Itself Mozilla — The User-Agent String's Chaotic History
Every Chrome browser sends a User-Agent header beginning with Mozilla/5.0. Firefox sends Mozilla/5.0. Safari sends Mozilla/5.0. Edge sends Mozilla/5.0. None of these browsers are Mozilla. This was not a mistake — it was deliberate compatibility theater accumulated over three decades, and it makes User-Agent strings one of the most confusing data formats in web development.
The origin: early web servers and browser detection scripts checked for "Mozilla" in the UA string to decide whether to serve rich content. When Internet Explorer launched in 1995, it added "Mozilla/1.22 compatible" to its UA to trick those servers into sending full-featured content. Every subsequent browser did the same: pretend to be Mozilla, then identify themselves with additional tokens after the compatibility marker. The result is that the "Mozilla/5.0" prefix is universal and meaningless — it carries no information about whether the browser actually is Firefox-based.
The Structure of a Real User-Agent String
Consider Chrome 120 on macOS:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Broken down:
Mozilla/5.0— compatibility token, meaningless(Macintosh; Intel Mac OS X 10_15_7)— platform: Mac, x86-64, macOS Catalina equivalentAppleWebKit/537.36— rendering engine: WebKit/Blink(KHTML, like Gecko)— historical compatibility token for KHTML-aware serversChrome/120.0.0.0— the actual browser and versionSafari/537.36— Chrome masquerades as Safari for Safari-detection scripts
Parsing this correctly requires a regex library that accounts for all the historical compatibility tokens — which is exactly what ua-parser-js does.
User-Agent Reduction: Chrome's Phased Freeze
Google began rolling out User-Agent Reduction in Chrome 101 (2022), with full rollout completing in Chrome 113 (2023). The change reduces the Chrome UA string to return a fixed OS version and CPU architecture string rather than the real values — the version now reports Windows NT 10.0 regardless of actual Windows version, and CPU shows only Win64; x64. The actual browser version continues to be reported.
The replacement mechanism is the User-Agent Client Hints API (Sec-CH-UA headers). Client Hints are opt-in: a server must request specific hints via response headers (Accept-CH: Sec-CH-UA-Platform-Version), and the browser sends the corresponding request header on the next request. Client Hints provide more granular information than the frozen UA string, but require active server-side implementation rather than passive string parsing.
Bot and Crawler Identification
Bot User-Agents are generally more informative than browser UAs — most well-behaved bots identify themselves clearly. Googlebot sends Googlebot/2.1 with a contact URL. Common patterns: Googlebot, Bingbot, Slurp (Yahoo), DuckDuckBot, Baiduspider, YandexBot. Malicious scrapers often clone browser UAs to avoid detection, which is why bot identification through UA alone is unreliable — use rate limiting, CAPTCHA challenges, and TLS fingerprinting for security purposes.
How to Use This Tool
- Paste any User-Agent string into the input field.
- The parsed components appear: browser name and version, rendering engine, OS and version, device type (desktop/mobile/tablet), and CPU architecture.
- Click "Use my UA" to automatically load your current browser's User-Agent string for inspection.
◇ FAQ
01 Why is my Chrome browser reporting Windows NT 10.0 even though I run Windows 11? +
Google's User-Agent Reduction (fully rolled out in Chrome 113) freezes the OS version in the UA string at Windows NT 10.0 for all Windows versions, including 11. The intent is to reduce passive fingerprinting. To get the real OS version, a server must request it via the Sec-CH-UA-Platform-Version Client Hint.
02 Can I trust the User-Agent string for security decisions? +
No. UA strings are set by the client and can be set to any value in about 5 seconds using browser developer tools or a simple script. Never use UA parsing to grant or deny access, infer the security context, or make any authentication decision. UA parsing is appropriate only for analytics, content optimization, and debugging.
03 How do I identify bots in server logs? +
Well-behaved bots self-identify in their UA strings (Googlebot, Bingbot, etc.). Verify bot claims by doing a reverse DNS lookup on the source IP and confirming the hostname matches the claimed bot's domain (e.g., googlebot.com for Googlebot) — anyone can set their UA to "Googlebot." Malicious bots typically clone browser UAs; identify them by behavior patterns (request rate, access patterns, TLS fingerprint) rather than UA alone.
04 What replaced User-Agent for browser detection? +
The User-Agent Client Hints API (UA-CH) is the modern replacement. The browser sends minimal info by default (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform). Servers that need more detail request specific hints via the Accept-CH response header, and the browser sends them on subsequent requests. This is an active, opt-in model rather than passively broadcasting everything in every request.
