A User-Agent parser takes the dense, cryptic string every browser sends with each request and breaks it into something readable: browser name and version, operating system, device type, and rendering engine. This tool parses any User-Agent string using pattern matching that runs entirely in your browser β paste one in, or just load the page and it parses your own browser's string automatically.
Arb Digital's developers use a User-Agent parser regularly when reviewing server logs, debugging device-specific layout bugs, or checking whether analytics traffic looks like a real visitor or an automated bot. We built this version as a free reference tool because most online UA parsers either require an account or send your string to a third-party server β this one never leaves your machine.
What This User-Agent Parser Does
The tool reads a User-Agent string and applies a sequence of pattern checks to identify the browser and its version, the operating system and version where detectable, whether the request looks like it came from a desktop, mobile, or tablet device, and which rendering engine powers it (Blink, Gecko, WebKit, or Trident). By default the input box loads with navigator.userAgent β your own browser's real UA string β so you can see how your own setup is identified immediately. You can replace it with any string you're investigating: one copied from a server access log, an API request header, a test automation script, or one of the reference examples in the table below, which you can click to load directly into the parser.
How to Use the User-Agent Parser
- Check your own browser first. The page loads with your real User-Agent string already parsed, so you can see immediately how a live UA breaks down.
- Paste a string to investigate. Copy a User-Agent from a log file, a support ticket, or an HTTP request and paste it into the input box.
- Click Parse. The result panel updates with browser, OS, device type, engine, and whether it's flagged as mobile.
- Browse or search the examples table below the parser for common real-world UA strings across major browsers and devices, and click any row to load it instantly.
- Cross-check anything suspicious. If a UA string looks malformed, inconsistent, or unusually generic, treat that as a signal worth investigating further rather than a definitive identification β see the honesty section below.
Anatomy of a User-Agent String
A typical desktop Chrome User-Agent looks like this: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36. Nearly every part of that string is a historical artifact rather than a literal description of the browser. The leading Mozilla/5.0 dates back to the 1990s browser wars and persists purely for compatibility, since countless older server-side scripts check for that token before serving modern content. The parenthesized platform section (Windows NT 10.0; Win64; x64) identifies the operating system and architecture. AppleWebKit/537.36 and the trailing Safari/537.36 are leftover tokens from WebKit's shared lineage with Chrome's Blink engine β Chrome still claims to be "Safari" in its own UA string for legacy compatibility reasons, which is exactly why naive substring checks for "Safari" incorrectly match Chrome, Edge, and Opera too. The actual identifying token for the real browser and version comes last or near-last β Chrome/124.0.0.0 in this example β which is why accurate parsing requires checking tokens in a specific priority order, not just searching for the first familiar name.
Why Detection Order Matters
Correctly identifying a browser from its User-Agent requires checking the most specific, most likely-to-be-spoofed-as tokens first. Microsoft Edge (Chromium-based) includes both Chrome/ and Safari/ tokens in its UA string, alongside its own Edg/ token β so a parser must check for Edg/ before it checks for Chrome/, or every Edge visitor gets misidentified as Chrome. The same logic applies to Opera (which uses an OPR/ token), Samsung Internet (SamsungBrowser/), and Chrome (Chrome/) β all of them are Chromium-based and all of them carry a trailing Safari/ token for legacy compatibility, so genuine Safari can only be correctly identified by confirming the Chrome/, Edg/, OPR/, and SamsungBrowser/ tokens are all absent. This tool's parsing logic follows that same priority order internally, which is the standard approach used by production User-Agent parsing libraries.
Device Type Detection: Desktop, Mobile, and Tablet
Device type detection relies on a smaller set of signals layered on top of the OS check. The literal word Mobile appearing in the UA string is the strongest signal of a phone-class device, and it's present on nearly every mobile Chrome, Safari, and Firefox UA string on iOS and Android. Tablets are trickier: an iPad running a recent iOS version can report a UA string nearly identical to a Mac's, and Android tablets typically include Android but deliberately omit the Mobile token specifically so responsive websites treat them more like a desktop-class viewport. That's why this parser treats "Android without the Mobile token" and "iPad" as tablet signals distinct from the more straightforward "contains Mobile" desktop-versus-phone check.
Rendering Engines Behind the Browsers
Underneath the browser brand names, only a handful of rendering engines actually exist. Blink, a fork of WebKit maintained by Google, powers Chrome, Edge, Opera, Samsung Internet, and most other Chromium-based browsers β meaning the large majority of desktop and Android browser market share runs the same underlying engine despite different branding. WebKit powers Safari and, notably, every browser on iOS regardless of its name, because Apple's App Store policy requires all iOS browsers to use WebKit under the hood β so "Chrome for iOS" and "Firefox for iOS" are actually WebKit with a different interface layered on top. Gecko is Mozilla's engine, powering Firefox and its variants. Trident was the engine behind legacy Internet Explorer, now essentially extinct in current browsing data outside legacy enterprise environments. Knowing the engine behind a UA string matters for understanding which rendering quirks and feature-support gaps to expect, independent of the marketing name on the browser icon.
Why User-Agent Detection Isn't Fully Reliable
It's important to be upfront about the limits of what any User-Agent parser β including this one β can tell you with certainty. A User-Agent string is simply a value the client sends in an HTTP header; nothing stops a browser, a script, a bot, or a browser extension from sending any string at all, whether spoofed manually, rotated automatically by a scraping tool, or overridden by developer tools. Treating User-Agent detection as a security boundary β for example, blocking or trusting a request purely because its UA string claims to be a specific browser β is a well-known and easily bypassed mistake.
Modern browsers are also actively making UA strings less precise over time, a trend usually called "User-Agent freezing" or "User-Agent reduction." Chrome has progressively frozen and simplified the version and platform details in its default UA string, encouraging developers to migrate to the newer User-Agent Client Hints API (documented on MDN) for anything requiring granular, opt-in device and platform data instead. Safari has long reported a generic, infrequently updated version number in its UA string regardless of the actual installed version, specifically to reduce fingerprinting. The practical takeaway is that User-Agent parsing remains genuinely useful for broad analytics, log triage, and quick debugging, but it should never be the sole basis for a security decision, and it will only get less granular as more privacy-focused changes roll out across browsers.
Arb Digital builds fast, cross-device websites and can help diagnose analytics or rendering discrepancies tied to browser or device detection β explore our other free tools below or get in touch.
Contact Arb Digital All Free ToolsCommon Mistakes to Avoid
- Using User-Agent checks as a security gate. UA strings are trivially spoofable β never rely on them to block or allow access on their own.
- Checking for "Safari" without excluding Chromium browsers. Chrome, Edge, Opera, and Samsung Internet all include a "Safari" token; check for their own specific tokens first.
- Assuming Android UA strings without "Mobile" are phones. The absence of the Mobile token on an Android device is the standard signal for a tablet, not a bug in the string.
- Expecting precise version numbers going forward. User-Agent freezing means version details in the raw string are becoming less reliable over time β use Client Hints for anything requiring accuracy.
- Ignoring malformed or unusually generic UA strings. While not proof of anything on their own, they're a reasonable signal to look closer at other request characteristics when investigating bot traffic.
Related Free Tools From Arb Digital
Pair this User-Agent parser with our HTTP Status Code Lookup when investigating request and response behavior, or the MIME Type Lookup for content-type debugging. Working with raw text or characters from log files? Try the ASCII Table or the Base64 Encoder/Decoder. You'll find every free utility we've built in the free online tools hub.
Frequently Asked Questions
A typical User-Agent string can reveal the browser name and version, the operating system, and general device type (desktop, mobile, or tablet). It cannot reliably reveal exact hardware, precise OS build numbers, or a user's identity.
Yes, easily. Any client can send whatever User-Agent string it wants, whether through browser developer tools, an extension, a script, or a testing tool, which is why UA strings should never be used as a security control.
All of them are Chromium-based browsers descended from the same WebKit lineage as Safari, and they kept a trailing Safari token for backward compatibility with older websites that check for it.
Browsers, especially Chrome and Safari, are progressively freezing or simplifying User-Agent details to reduce fingerprinting and improve privacy, shifting toward the more granular, opt-in User-Agent Client Hints API instead.
Most mobile browsers include the literal word "Mobile" in their User-Agent string. Its absence, combined with an "Android" or "iPad" token, typically indicates a tablet rather than a phone.
Both use WebKit. Apple's App Store policy requires all browsers on iOS to use WebKit under the hood, so "Chrome for iOS" and "Firefox for iOS" are WebKit-based despite their branding.
This User-Agent parser runs entirely in your browser β no data is sent to any server, and no signup is required.
