A User-Agent string looks like a single unreadable token, but it is actually several pieces of information mashed together for historical reasons that go back to browsers pretending to be other browsers to pass early compatibility checks. Reading it by eye means knowing which part is a genuine signal and which part is leftover legacy noise, and this tool exists so you do not have to memorise that.
Everything happens locally using regular expression matching against known patterns. As a user agent string decoder it never phones home: the string you paste, which is often attached to a support ticket describing a bug that only one customer seems to hit, never leaves your machine to be parsed.
Why every user agent parser has to deal with impersonation
Nearly every modern browser includes the word Mozilla at the start of its User-Agent string, a holdover from the mid 1990s when Netscape Navigator's code name was Mozilla and sites checked for that token before serving pages that used features only Navigator supported. When Internet Explorer wanted the same pages, it added Mozilla to its own string too, and every browser since has kept doing the same thing to avoid being blocked by the same kind of check.
Chrome goes further and includes both Safari and the word like Gecko in its string, because Chrome's engine descended from code that once powered Safari, and because sites once checked for like Gecko before serving modern layout. The practical result is that almost any real browser's raw string mentions two or three browsers it is not, and a naive parser that just checks for the first familiar word it finds will get the answer wrong most of the time.
- Check tokens in order of specificity, most distinctive engines and browsers first.
- Treat Edg as Microsoft Edge before falling through to a Chrome match, since Edge also carries a Chrome token.
- Treat OPR as Opera before Chrome, for the same reason.
- Only fall back to Chrome once every browser that also carries a Chrome token has been ruled out.
- Use Safari only when neither Chrome, Edge nor Opera tokens are present, since real Safari never mentions any of them.
What this tool extracts when you parse user agent string values
Four pieces of information come out of every successful parse: the browser and its version number, the rendering engine responsible for turning HTML and CSS into pixels, the operating system and its version where the string exposes one, and a device type classification of desktop, mobile or tablet based on the presence of tokens like Mobile or Tablet.
Version numbers are pulled directly from the token that names the browser, so Chrome 128 and Chrome 91 are reported as different versions of the same browser rather than being collapsed into one bucket, which matters when a bug report says a feature broke in a specific release.
How the rendering engine relates to the browser detection tool result
The rendering engine is often more useful than the browser name for predicting compatibility, because several browsers share one engine. Chrome, Edge, Opera, Brave and most Android browsers all run on Blink, the engine forked from WebKit that Google maintains. Safari and every browser on iOS, including Chrome for iOS, are required by Apple's platform rules to use WebKit rather than their normal engine. Firefox is the last major browser still using Gecko.
That last point about iOS is the one that trips people up most often. A user agent string containing CriOS instead of Chrome tells you it is Chrome for iOS, and despite the name, its actual rendering behaviour matches Safari's WebKit rather than desktop Chrome's Blink, because Apple requires every browser on iOS to use the same system provided engine underneath a different interface.
Detecting device type from user agent tokens
Mobile detection relies on a small set of conventional tokens rather than any formal standard. Android devices include the literal word Mobile in their string when the device is a phone sized form factor, and omit it for tablets, which is the main signal this tool uses to tell an Android phone from an Android tablet. iOS uses iPhone, iPad and iPod as distinct tokens, so an iPad is identifiable directly by name rather than by the absence of a word.
None of this is guaranteed to be accurate. A user can override their browser's reported user agent through developer tools or a browser extension, and some privacy focused browsers deliberately send a generic or randomised string to reduce fingerprinting. Detecting device type from user agent data is a heuristic that is right most of the time, not a reliable identity check.
Why User-Agent Client Hints are replacing this string
Because the User-Agent string became so overloaded with legacy tokens, browsers are moving toward User-Agent Client Hints, a newer set of HTTP headers and a matching JavaScript API that report the same information as separate, explicitly named fields instead of one string to reverse engineer. Chrome has already begun freezing parts of its User-Agent string and reducing how much version detail it exposes by default, pushing sites toward the new headers for anything more precise.
This user agent parser still matters during the transition, since a huge amount of existing server side logging, analytics tooling and legacy detection code reads the classic string and will keep doing so for years, and pasted strings from old log files are not going away just because a new API exists.
| Token | Indicates |
|---|---|
| Mozilla/5.0 | Legacy compatibility token present in almost every browser |
| AppleWebKit | The WebKit or Blink derived layout engine is in use |
| Gecko | Present in Firefox, and as "like Gecko" in many other browsers for compatibility |
| Chrome/ | Chrome or another Blink based browser, unless Edg or OPR also appears |
| Edg/ | Microsoft Edge, which also carries a Chrome token |
| Safari/ | WebKit based rendering, present even in non Safari browsers on iOS |
| Mobile | A phone sized form factor rather than a tablet or desktop |
How to parse a User-Agent string
- 1
Copy the User-Agent string
Take it from a server log, a bug report, or navigator.userAgent in your own browser's developer console.
- 2
Paste it into the tool
The full raw string is accepted exactly as copied, including any surrounding quotes.
- 3
Press parse
Pattern matching runs locally against known browser, engine, OS and device tokens.
- 4
Read the breakdown
Check the browser name and version, rendering engine, operating system and device type shown in the result.
Related tools worth bookmarking
Sources and further reading
- MDN: User-Agent headerReference documentation for the header's format and the common tokens browsers include in it.developer.mozilla.org
- RFC 9110: User-Agent field definitionThe HTTP specification's formal definition of the User-Agent request header field.rfc-editor.org
- Google: User-Agent reduction and Client HintsExplains why Chrome is reducing User-Agent string detail in favour of Client Hints headers.developers.google.com
Frequently asked questions
Common questions about the user agent parser.
Chrome's rendering engine descended from code that once powered Safari, and older sites checked for the word Safari before serving pages using modern layout features. Chrome kept the token for compatibility, so a genuine Chrome browser mentions Safari even though it is not Safari, which is exactly the kind of detail a user agent parser has to account for.
Mostly, but not with certainty. Device type is inferred from conventional tokens like Mobile and Tablet that almost every real browser includes honestly. A user can still override their reported string through developer tools or an extension, so treat the result as a strong signal rather than a guaranteed identity check.
No, despite sharing a name. Apple requires every browser on iOS to use the system WebKit engine, so Chrome for iOS, identified by the CriOS token in its string, actually renders pages using WebKit rather than the Blink engine that powers Chrome everywhere else, which can produce different compatibility behaviour.
No. The token list this parser checks against, Edg, OPR, CriOS and the rest, is bundled directly into the page, and the regular expression matching runs locally in your tab. A string copied out of a support ticket or an internal log file is matched without ever being sent anywhere.
Decades of impersonation tokens have made the classic string bloated and unreliable to parse precisely, so browsers are introducing User-Agent Client Hints, a set of separate headers reporting the same details explicitly. Chrome has already begun reducing the detail in its default string to push adoption of the newer headers.
An unrecognised string usually comes from an uncommon bot, an older device, or a browser that has been deliberately modified to send a generic value for privacy. The tool reports whichever fields it can match confidently and leaves the rest blank rather than guessing at a browser that is not actually indicated by any known token.