User Agent Parser

The value of the User-Agent HTTP request header — a line of text a client sends with every request to describe itself. Browsers use it to name their product, version and platform, and it is the oldest and least structured piece of client identification on the web.

Usually a product token and version, a platform section in parentheses, and a chain of compatibility tokens inherited from browsers that no longer exist. A typical Chrome string carries Mozilla/5.0, an operating system section, AppleWebKit/537.36, KHTML like Gecko, the real Chrome version, and a trailing Safari token. Only two of those describe the browser you are actually using.

Match product tokens in a specific order, most specific first, and take the first that fits. Order is the whole algorithm: an Edge string contains Chrome/, an Opera string contains Chrome/, and a Chrome string contains Safari/. Test for Chrome before Edge and Edge disappears. This parser runs its signatures as an ordered list for exactly that reason.

Look for the distinguishing token rather than the familiar one. Edge is Edg/, Opera is OPR/, Samsung Internet is SamsungBrowser/, Vivaldi is Vivaldi/ and Yandex is YaBrowser/ — each of which also carries Chrome/ and would be misread as Chrome by a naive check. Chrome is what is left once all of those have been ruled out.

From the platform section in the first set of parentheses: Windows NT for Windows, Macintosh for macOS, Android, iPhone or iPad for Apple mobile devices, CrOS for ChromeOS, X11 for desktop Linux. Order matters here too — Android strings contain the word Linux, and ChromeOS strings contain X11, so both must be checked before any Linux rule.

Because Windows 11 sends Windows NT 10.0, exactly as Windows 10 does. Microsoft never incremented the token, so no parser can tell the two apart from the string alone — anything claiming to is guessing. This tool reports “10 or 11” and labels it Likely rather than Detected. The real version is only available through User-Agent Client Hints.

Safari froze the reported macOS version at 10.15.7 from Big Sur onwards, as a fingerprinting-reduction measure, and Chrome on macOS does the same. The number is real but it is a floor, not a reading: it means 10.15.7 or anything later. This tool shows it as “10.15.7 or later” rather than pretending to a precision the string does not have.

The type, usually. The specific device, rarely. Android strings often carry a model code such as Pixel 8 or SM-S928B, which is genuinely useful. Desktop strings carry nothing — a laptop and a tower are indistinguishable. And Apple exposes nothing beyond “iPhone” or “iPad”.

On Android, sometimes — the model code is in the platform section, and the brand can often be inferred from its prefix. On iOS, never: every iPhone sends the same iPhone token regardless of the model, so any tool that names an iPhone 15 from a User-Agent has invented it. Chrome's reduced User-Agent has also replaced the Android model with a placeholder, described below.

That is Chrome's reduced User-Agent. Since Chrome 110, Android strings report a fixed “Android 10; K” whatever the real version and device are. K is not a phone — it is the placeholder Chrome sends instead of one. This tool detects the pattern, reports no model, and says why rather than leaving a blank.

The User-Agent is one unstructured string sent with every request whether it is wanted or not. Client Hints are separate, structured headers — Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile and others — that a server requests and a browser may choose to send. Hints give better data in a parseable form, but they are opt-in, request-time, and not implemented everywhere. A parser cannot recover from the string what the string did not contain.

Completely and trivially. It is a header the client sets. Browsers offer it in developer tools, extensions rewrite it, every HTTP library sets it with one argument, and curl does it with a flag. There is no mechanism anywhere in HTTP that verifies it.

No. Never use it for authentication, authorisation, access control or anything a determined party benefits from bypassing, because bypassing it is a single header. It is fine for analytics, for choosing which download to offer, and for deciding whether to show a browser-upgrade prompt — cases where being wrong is an inconvenience rather than a breach.

The string is the first step and not the last. Googlebot identifies itself with a Googlebot/2.1 token, which this tool detects and shows the matching evidence for. But anyone can send that token, so Google's own guidance is to verify with a reverse DNS lookup on the requesting IP and a forward lookup back — a server-side check no parser can perform from the string.

Any string a non-browser client sends. Well-behaved crawlers name themselves and include a URL explaining what they are, because they want to be identifiable and to be governed by robots.txt. Beyond the named ones, generic markers like bot, crawler and spider catch the rest — weaker evidence, and this tool labels it as such rather than reporting it with the same confidence.

Nothing, now. In 1994 Netscape identified itself as Mozilla; servers began requiring the token before serving modern pages; Internet Explorer copied it to avoid being downgraded; everything since has copied it too. Today essentially every browser sends Mozilla/5.0 and it means only “I am a web browser”. It is not a claim about Firefox.

It is a leftover from before Chromium forked. Chrome was built on WebKit until 2013, when Blink split off; the AppleWebKit/537.36 token stayed for compatibility and has been frozen at that version ever since. Reading it literally makes every Chrome user a WebKit user, which is why this tool derives the engine from the browser rather than from that token.

The same kind of leftover, one layer further on. Chrome kept a trailing Safari/537.36 so sites sniffing for Safari would serve it modern content. The distinguishing feature of real Safari is the Version/ token, which Safari sends and Chromium does not — that is what this parser tests.

Match Chrome/ and its version, but only after ruling out Edg/, OPR/, SamsungBrowser/, Vivaldi/, YaBrowser/, Chromium/ and HeadlessChrome/. All of them carry Chrome/ as well. On iOS, Chrome is CriOS/ instead, and it is not running Blink — see below.

Match Firefox/ and read the version after it; the Gecko engine version is in the rv: token. Firefox is the easiest of the major browsers to detect because it never adopted the WebKit or Safari compatibility tokens — a Firefox string contains no AppleWebKit at all. Watch for SeaMonkey and Waterfox, which also carry a Firefox token.

Require both a Version/ token and a Safari/ token, and require the absence of Chrome, Chromium, CriOS, FxiOS, EdgiOS and OPiOS. Testing for Safari/ alone matches nearly every Chromium browser ever released, which is the most common single mistake in browser sniffing.

Match Edg/ for the Chromium-based Edge, EdgA/ on Android and EdgiOS/ on iOS. The legacy pre-Chromium Edge used Edge/ with a slash and ran EdgeHTML — a different browser and a different engine, so it is worth reporting separately. All of them must be checked before Chrome.

Look for the Mobile token, and know the Android convention: Google's guidance is that phones include Mobile and tablets omit it, so on Android the absence of a token is what identifies a tablet. iPhone and iPad have their own tokens. This is reliable for the broad type and is not a substitute for a CSS media query if what you actually care about is screen size.

No, and this catches a lot of parsers out. Apple's App Store rules require browsers on iOS to use the system WebKit, so Chrome on iPhone is Chrome's interface over WebKit rather than Blink. Firefox on iOS is the same — Firefox's interface over WebKit, not Gecko. This tool reports the engine that actually renders the page.

The major version, reliably. The full version, less so than it used to be: Chrome has frozen the minor, build and patch numbers at 0.0.0 since Chrome 101, so a string reading Chrome/131.0.0.0 tells you 131 and nothing more. The exact build is available through Client Hints, if the server asks and the browser agrees.

Because every token in them was added to stop some site from serving a degraded page, and removing one risks breaking sites that are still checking for it thirty years later. The string is an archaeological record of compatibility bluffs, and it grows because nothing in it can safely be taken away.

Parsing reads a string the client sent about itself. Browser detection in the modern sense means feature detection — asking whether the API you need actually exists, rather than inferring it from a name and a version. Feature detection is correct for deciding what your code can do; parsing is for analytics, logging and support, where you want to know what a client claimed rather than what it can do.

Accurate about what the string says, which is a different question from what the client is. For mainstream browsers the browser, version family, OS family and device type are reliable. OS version, device model and architecture are frequently unavailable, and both Chrome's reduction and Safari's version freeze are removing more over time. This tool marks every field Detected, Likely or Not detected rather than filling gaps with plausible guesses.

Because every Mac reports Intel, including Apple Silicon ones — Apple kept the token so existing sniffers would not break. A Mac string cannot distinguish an M-series chip from an Intel one, so reporting x86-64 from it would be repeating a compatibility fiction as a fact. This tool reports nothing there and explains why.

Yes. Every feature is free, with no account, no sign-up and no limit on how many strings you parse.

No. Parsing a User-Agent is string matching, and all of it happens in your browser — there is no backend involved and no request made. Nothing is stored, and unlike the other tools here this one deliberately does not offer a shareable link, because a User-Agent identifies the person who sent it much more closely than a formatted document does.