What this parser pulls apart
Every HTTP request your browser sends carries a User-Agent header. It’s a long, messy string stuffed with browser names, version numbers, OS hints, and historical baggage that nobody bothers to clean up. Paste one here and you get the readable version: which browser, which version, what OS, what kind of device, and the rendering engine underneath.
Try the “Use my browser” button. It drops your own navigator.userAgent straight into the box so you can see exactly what sites read when you visit them. Handy when you’re debugging a layout bug that only shows up on your machine.
Here’s a real one:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36That decodes to Chrome 124 on 64-bit Windows 10/11, desktop, Blink engine. Notice it still claims to be “Mozilla” and “Safari” and mentions “KHTML.” None of that is true anymore. Browsers copied each other’s UA strings for two decades to dodge old server-side sniffing, and the cruft never went away.
Reading the fields
Browser and version come from tokens like Chrome/124, Firefox/126, or Version/17.4 Safari. Edge, Opera, Brave, Vivaldi, and Samsung Internet all ride on Chromium, so they tack their own token on the end. The parser checks for those first, since a naive scan would just call every Chromium browser “Chrome.”
Operating system is guessed from Windows NT 10.0, Mac OS X, Android 14, iPhone OS 17_4, and similar markers. Apple freezes the macOS version at 10.15.7 in Safari now, so don’t trust that number on a Mac. It’s a privacy move, not a bug.
Device type lands in one of four buckets: desktop, mobile, tablet, or bot. The Mobile token, iPhone, and Android ... Mobile push it toward mobile. An iPad or an Android tablet without the Mobile token reads as a tablet. Strings like Googlebot, bingbot, curl, or python-requests get flagged as bots.
Rendering engine is Blink for Chromium browsers, WebKit for Safari, and Gecko for Firefox. The raw UA always says AppleWebKit even on Chrome, so the parser relabels it to Blink when it spots a Chromium token.
Why the result is best-effort
UA strings lie. A lot.
Set your expectations accordingly. Anyone can spoof the header with a single line of curl. Privacy browsers ship fake or generic strings on purpose. Chrome’s UA-reduction effort has been trimming version detail and pinning the OS platform, so modern strings carry less than they used to. The parser uses pattern matching, which gets the common cases right and shrugs at the weird ones.
Bottom line: use this for debugging, analytics sanity checks, and curiosity. Don’t use it as a security gate. If a request claims to be Googlebot, verify it with a reverse DNS lookup before you trust it.
FAQ
Does anything I paste get uploaded? Nope. The parsing runs entirely in JavaScript on your page. Close the tab and it’s gone.
Why does my Chrome string say Safari and Mozilla?
Legacy compatibility. Browsers inherited each other’s tokens over the years so old servers wouldn’t block them. Chrome keeps Safari/537.36 and Mozilla/5.0 purely for backward compatibility.
Can I trust the OS version it shows? Usually on Windows and Android. On macOS and iOS, less so. Apple now freezes or rounds those values to reduce fingerprinting, so a Mac might report 10.15.7 even when it’s running something far newer.
How does it tell a tablet from a phone?
The Mobile token is the giveaway. Phones include it, most tablets don’t. An iPad reports iPad (or masquerades as a Mac in desktop mode), and an Android tablet drops the Mobile keyword. It’s a heuristic, so edge cases slip through.
Will it catch every browser? The mainstream ones, yes: Chrome, Firefox, Safari, Edge, Opera, Brave, Vivaldi, Samsung Internet. Obscure or brand-new browsers might fall back to “Unknown” if their token isn’t recognized.
Can a server be fooled by a fake User-Agent? Easily. That’s the whole point of the warning. The header is client-controlled, so never rely on it for authentication or access control.