💻 Coding

User Agent Parser

Paste any browser User-Agent string and break it down into browser, operating system, device type, and rendering engine.

Browser
Browser Version
Operating System
Device Type
Rendering Engine

About the User Agent Parser

The box loads with your own browser's real User-Agent string so there's something to look at right away, and "Parse My Browser" refreshes it if you've typed over it. Detection runs through a set of ordered regular expressions rather than a lookup table: Edge and Opera are checked before Chrome since their Chromium-based strings also contain "Chrome/", and Safari is only matched when "Chrome/" is absent, since real Chrome user agents contain "Safari/" too. Any field the patterns can't confidently identify shows as "Unknown" instead of guessing or breaking.

Why user agent strings are such a historical tangle in the first place

The ordered-check approach exists because of decades of browser vendors deliberately impersonating each other for compatibility reasons. When Chrome launched, websites were already sniffing for "Safari" and "Mozilla" in the user agent to decide whether to serve modern layouts, so Chrome's user agent string still opens with "Mozilla/5.0" and includes "Safari/" even though it's neither, it inherited those tokens purely so older website compatibility checks wouldn't break. That's exactly why this tool's detection has to check the most specific, exclusive marker first (a real Edge string always contains "Edg/") before falling back to broader, inherited markers, a naive single keyword search for "Safari" would misidentify the overwhelming majority of real-world Chrome, Edge, and Opera users as Safari.

A real, unfixable limitation: Windows 10 and 11 report identically

Microsoft never incremented the underlying NT kernel version number when Windows 11 launched, it's still internally NT 10.0, exactly the same value Windows 10 reports. That means the user agent string itself contains no information that could distinguish the two, which is why this tool's Windows detection deliberately maps NT 10.0 to the combined label "Windows 10/11" rather than falsely claiming certainty it can't actually have. This isn't a gap in this tool's parsing logic, it's a genuine limitation of the User-Agent format itself, no parser, however sophisticated, can recover information the string never contained.

Another real limitation: modern iPads can report themselves as Macs

Since iPadOS 13, Safari on iPad defaults to a "desktop" user agent that specifically identifies as "Macintosh" rather than "iPad," a deliberate choice by Apple so websites serve the full desktop layout instead of a scaled-down mobile version by default. That means a genuine, current iPad can be entirely indistinguishable from an actual Mac purely by reading its user agent string. This is true of every user-agent-based detection method, not something specific to this tool, and it's one of several reasons device and OS detection based on this string alone has become progressively less reliable over the past several years.

How the rendering engine gets inferred, and why it checks the browser first

Rather than independently re-scanning the raw user agent string for engine-specific keywords, this tool first checks which browser it already identified and infers the engine from that (Firefox implies Gecko, Safari implies WebKit, any Chromium-based browser implies Blink), only falling back to directly searching for "AppleWebKit" or "Gecko" substrings if the browser itself couldn't be determined. That ordering matters for the same historical-spoofing reason covered above, nearly every modern browser's user agent string contains "AppleWebKit" somewhere in it as an inherited legacy compatibility token, regardless of what engine it actually runs, so a direct keyword search alone would misidentify Blink and Gecko browsers as WebKit far too often.

Why the industry is slowly moving away from free-text User-Agent strings

This exact tangle of inherited tokens, deliberate impersonation, and information that's simply no longer present (like the Windows 10 versus 11 case) is a large part of why the newer User-Agent Client Hints API exists, an explicitly structured, opt-in alternative some browsers now support that reports browser and platform information as distinct, unambiguous fields instead of one long string requiring this kind of pattern-matching archaeology to interpret. The classic User-Agent header remains universally present for now, which is why a parser like this one is still genuinely useful, but it's worth knowing the format itself is a known, acknowledged weak point in modern web development, not just something this specific tool struggles with.

Frequently Asked Questions

Why does the detection logic check for Edge and Opera before checking for Chrome?

Both Edge and Opera are Chromium-based and include "Chrome/" in their user agent strings as an inherited compatibility token. Checking for their more specific, exclusive markers ("Edg/" and "OPR/") first prevents them from being misidentified as Chrome.

Can this tool tell Windows 10 apart from Windows 11?

No, and no user agent parser can, Microsoft never changed the underlying NT kernel version number for Windows 11, so both report identically as "Windows NT 10.0." This tool reflects that honestly with a combined "Windows 10/11" label rather than falsely claiming certainty it can't have.

Why might a real iPad get detected as a Mac?

Since iPadOS 13, Safari on iPad defaults to identifying itself as "Macintosh" in the user agent so websites serve the full desktop layout. This makes a genuine iPad indistinguishable from an actual Mac by user agent string alone, a limitation of the format itself, not this specific tool.

Why does the tool infer the rendering engine from the browser name instead of scanning the string directly?

Nearly every modern browser's user agent string contains "AppleWebKit" as an inherited legacy token regardless of its actual engine, so a direct keyword search alone would misidentify Blink and Gecko browsers as WebKit too often. Inferring from the already-detected browser name first avoids that false positive.

Is the User-Agent string still a reliable way to detect browsers and devices?

It's become progressively less reliable due to decades of browsers deliberately impersonating each other for compatibility, which is part of why the newer User-Agent Client Hints API exists as a more structured, explicit alternative. The classic string is still universal for now, which is why parsing it remains useful.

What happens if the parser can't confidently identify a field?

It shows "Unknown" for that field rather than guessing. This is a deliberate design choice, since a confident-looking but wrong guess would be more misleading than honestly reporting that the pattern didn't match anything recognized.