What it does
Paste a user agent string and this tool breaks it into the four things people actually want from it: the browser and its version, the rendering engine, the operating system, and the device type. It also shows your own browser's string, so you can see what you are sending to every site you visit.
It runs entirely in your browser. The string you paste is never sent to our server, logged, or stored.
One thing to be clear about before you rely on any of it: a user agent string is a self-declaration, not proof. It is a header the client chooses to send, it can be set to anything, and — as the examples below show — even the honest ones are full of claims that are not true. Parse it for analytics and diagnostics; never for a security decision.
How it works
The User-Agent header has a nominal structure — a product token, an optional parenthesised comment with platform details, then further product tokens for subsystems. In practice that structure was abandoned decades ago, and a modern string is closer to a geological cross-section: layers of tokens deposited by successive rounds of compatibility fakery, none of which anyone dares remove.
Why every browser says Mozilla
In 1994 Netscape Navigator identified itself as Mozilla and supported frames, which the older Mosaic did not. Servers began sniffing for Mozilla before serving the frame-based version of a page. So when Internet Explorer shipped frame support, it had a problem: honest identification got it the degraded page. Its answer was to claim Mozilla/1.22 (compatible; MSIE 2.0; ...) — announce itself as the thing servers were checking for, and put its real identity in the comment.
Every browser since has faced the same choice and made the same decision. The result is a cargo cult where Mozilla/5.0 is a meaningless universal prefix, kept only because some server somewhere still checks for it. Nothing about it distinguishes anything.
Why Chrome says Safari, and Safari says KHTML
The same mechanism repeated. Safari was built on KHTML, the engine from the KDE project's Konqueror, so it advertised AppleWebKit ... (KHTML, like Gecko) — claiming lineage from KHTML and behavioural similarity to Firefox's Gecko in one breath. When Chrome launched in 2008 it used WebKit and inherited the whole string, then appended Safari/537.36 so that sites already serving good code to Safari would serve it to Chrome too. In 2013 Chrome forked WebKit into Blink and has not shared an engine with Safari since — but the AppleWebKit and Safari tokens stayed, because removing them would have broken sniffing code that predates the fork.
So a Chrome string simultaneously claims to be Mozilla, AppleWebKit, KHTML, like Gecko, and Safari. It is none of them. Correctly reading it means ignoring almost every token in it and looking only at Chrome/.
Why Edge says Chrome — and the bug it causes
Since 2020 Edge has been built on Chromium, and it declares itself the way Chrome-based browsers do: full Chrome string first, its own Edg/ token appended at the end. Opera does the same with OPR/, and so do most Chromium derivatives.
This produces the single most common user agent parsing bug. Code that tests for Chrome before testing for Edg matches on the Chrome token and never reaches the Edge branch, so every Edge user is silently counted as a Chrome user. The fix is ordering: check for the most specific token first, and treat plain Chrome as the fallback only after every derivative has been ruled out.
Where the version really lives
Not always where it looks. In Safari, Safari/605.1.15 is the WebKit build number, not the browser version — the actual release is in the Version/ token. In Firefox, the Gecko/20100101 token is a hardcoded date that has not changed since 2010, frozen because sites were parsing it; the real version is in rv: and Firefox/. Chrome on iOS uses CriOS/ rather than Chrome/, and Firefox on iOS uses FxiOS/.
The platform lies
The operating system tokens are, if anything, less reliable than the browser ones.
- Windows 11 is indistinguishable from Windows 10. Both report
Windows NT 10.0. Microsoft never bumped the token for Windows 11, so no parser — this one included — can tell them apart from the string alone. Any tool that confidently reports "Windows 11" is guessing. - macOS is frozen at
10_15_7. Since Big Sur, Safari and Chrome both report that version regardless of the actual OS, deliberately, to avoid leaking a fingerprinting signal. It means "10.15 or later" and nothing more. - An iPad claims to be a Macintosh. Since iPadOS 13, Safari on iPad requests desktop sites by default and sends a Mac string to match. Unless something else in the string gives it away, or the page separately checks for touch support, iPad traffic lands in your desktop bucket — which quietly corrupts device breakdowns in analytics and can hide a broken tablet layout for months.
- Android reports Linux first. The platform comment starts
Linux; Android 14; ..., and whether the device is a phone or a tablet is signalled by the presence or absence of theMobiletoken beforeSafari, not by anything more explicit.
Browser and engine do not always match
Usually the engine follows from the browser: Chrome and Edge mean Blink, Safari means WebKit, Firefox means Gecko. iOS is the exception. Apple's App Store rules long required every iOS browser to use the system WebKit engine, so Chrome on iPhone is Chrome in interface, sync and branding, but WebKit underneath. Treating CriOS as Blink will give you the wrong answer about which CSS and JavaScript features are available.
User-Agent Reduction and Client Hints
The string is being deliberately drained of information. Under User-Agent Reduction, Chrome now freezes the browser's minor version at 0.0.0 and pins the platform version, so two different Chrome builds on two different Windows versions produce byte-identical strings. That detail is not hidden from this tool — it is no longer present in the string at all.
The replacement is User-Agent Client Hints: a set of Sec-CH-UA request headers and the navigator.userAgentData JavaScript API. The design inverts the default — a site gets a low-entropy summary automatically, and has to explicitly request high-entropy values such as the full platform version or the device model. Sites that need the detail can still ask; sites that were only ever getting it by accident no longer do.
The motivation is fingerprinting. Combined with screen size, time zone, fonts and a handful of other passively available signals, a detailed user agent string contributes enough entropy to help identify a specific browser across sites without any cookie. Reducing it removes bits from that identifier. The trade-off is exactly what you see here: less to parse, and more answers that honestly have to be a range rather than a value.
When the answer is "unknown"
Plenty of user agents are not browsers — crawlers, monitoring probes, HTTP libraries, and command-line tools. For those the only knowable fact is usually the client name and version. A parser that assumes every string is a browser will manufacture an operating system and a device type out of nothing, which is worse than a blank field. This tool leaves unknowns blank.
Worked example
Take Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36. That parses as Chrome 126 on the Blink engine, running Windows 10 or 11 on a desktop. Every other token in it is historical: it is not Mozilla, not AppleWebKit, not KHTML, not Gecko, not Safari. And the operating system genuinely cannot be narrowed further than "10 or 11".
Now append one token: Edg/126.0.2592.87. The string is otherwise identical, but the correct answer becomes Edge 126, still on Blink. A parser that checked for Chrome first would have stopped one token too early and reported Chrome.
Two more from the test set. Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/126.0.6478.54 Mobile/15E148 Safari/604.1 is Chrome on WebKit — the browser and the engine really do come from different vendors here. And Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15 iPad is an iPad in desktop mode: it says Macintosh, but the trailing iPad token gives it away as iPadOS on a tablet. Strip that one token and it is unrecognisable from a Mac.
Finally curl/8.7.1: client curl 8.7.1, and nothing else. No engine, no operating system, no device — because none of that is in the string, and inventing it would be the bug.
Common uses
- Reading server logs: turning a wall of raw strings into a browser and OS breakdown when investigating an error that only some visitors hit.
- Reproducing a bug report: a user pastes their string and you find out they are on Chrome for iOS, so the problem is a WebKit one, not a Blink one.
- Checking analytics device splits: verifying whether iPads are being counted as desktops, which is the usual explanation for a tablet share that looks implausibly low.
- Testing detection code: confirming that Edge, Opera and other Chromium derivatives are classified correctly before the ordering bug reaches production.
- Auditing what you leak: seeing your own string as a site sees it, and how much of it is a fingerprinting signal.
- Debugging spoofed agents: checking what a scraper, monitoring probe, or a browser with a UA override is actually announcing.
Frequently asked
Why does my browser say Mozilla when I don't use Firefox?
Because Mozilla/5.0 stopped meaning Mozilla in the 1990s. It began as Netscape Navigator's product token, servers started sniffing for it to decide which version of a page to serve, and every subsequent browser copied it to avoid being served the degraded page. It survives today as a vestigial prefix that identifies nothing — Firefox, Chrome, Safari and Edge all send it.
Why does Chrome say Safari?
Chrome originally used Apple's WebKit engine and copied Safari's user agent format, including the trailing Safari/537.36 token, so that sites already serving modern code to Safari would serve it to Chrome too. Chrome forked WebKit into Blink in 2013 and the two have been separate engines ever since, but the token was left in place because removing it would break sniffing code written before the fork.
Can I change my user agent?
Yes, easily. Browser developer tools have a device-emulation setting that overrides it, extensions can rewrite it, and any HTTP client can send whatever it likes — curl -A is one flag. That is precisely why the string is evidence of nothing. Use it for aggregate analytics and diagnostics, and never as an access-control or anti-abuse check, since anyone motivated enough to bypass such a check will do so in seconds.
Is a user agent string personal data? Can it identify me?
On its own it is not identifying: millions of people send an identical Chrome-on-Windows string, which is part of the point of User-Agent Reduction. But it contributes entropy to a browser fingerprint — combined with screen dimensions, time zone, installed fonts, language and similar passively readable signals, it helps narrow you to a small group or an individual, with no cookie involved. Under UK GDPR that combination can constitute personal data in context. An unusual string (an old browser, a rare OS, a modified agent) makes you more distinctive, not less.
Why can't it tell Windows 10 from Windows 11?
Because the string does not contain the answer. Windows 11 reports Windows NT 10.0, exactly as Windows 10 does — Microsoft never incremented the token, largely because version-checking code in the wild would have broken. The distinction is only available through the high-entropy Client Hint Sec-CH-UA-Platform-Version, which a site has to explicitly request and the browser can decline. Any parser claiming to identify Windows 11 from the user agent alone is inferring, not reading.
Why does my iPad show up as a Mac?
Since iPadOS 13, Safari on iPad requests desktop sites by default and sends a Macintosh user agent string to go with it. It was intended to stop iPads receiving cut-down phone layouts, and it worked — at the cost of making iPad traffic invisible to user agent parsing. Distinguishing them reliably needs another signal, such as touch-point support alongside a Mac platform string.
Is the user agent string going away?
Not removed, but progressively emptied. Chrome's User-Agent Reduction freezes the parts that carried the most detail, and the header will keep being sent for compatibility. New code should read navigator.userAgentData or the Sec-CH-UA headers, request only the high-entropy values it genuinely needs, and — better still — feature-detect rather than browser-detect wherever the goal is deciding whether a capability exists.
What is the difference between a browser and an engine?
The engine parses HTML and CSS and runs JavaScript; the browser is the application wrapped around it. Blink powers Chrome, Edge, Opera and Brave; WebKit powers Safari and every browser on iOS; Gecko powers Firefox. Which engine you have determines which web features work, so for compatibility questions the engine is the more useful field of the two.