User-Agent Parser
How to use this User-Agent parser
- Paste any User-Agent string, or click "Use my browser's UA".
- See the browser, engine, OS, and device type broken down instantly.
- Useful for debugging analytics, log files, or browser-specific bugs.
What is a User-Agent string?
It's a text header sent by every browser with each request, identifying the browser, rendering engine, operating system, and device — servers use it to serve appropriate content or for analytics.
Why does the User-Agent string mention multiple browsers?
For historical compatibility, most browsers include tokens from older browsers they're compatible with (like "Mozilla" and "Safari" appearing even in Chrome) — a quirk dating back to the "browser wars" that never went away.
Can User-Agent strings be faked?
Yes, easily — any browser's developer tools or extensions can override it, so User-Agent detection should never be relied on for security purposes, only for optional feature adjustments.
Why the rendering engine token is often more reliable than the browser name
A User-Agent string identifies more than just the browser's own brand name — it also names the underlying rendering engine actually responsible for parsing and displaying web pages, and this engine token is frequently more useful for practical compatibility decisions than the browser name itself. Chrome, Edge, Opera, Brave, and many other browsers are all built on the same Blink rendering engine (itself a fork of WebKit), meaning they share the vast majority of their actual page-rendering behavior despite having entirely different brand names and separate development teams. Safari uses WebKit directly, and Firefox uses its own independent Gecko engine. If a compatibility issue is genuinely rendering-related, checking the engine token rather than the specific browser name often gives a more accurate, more broadly applicable picture of which browsers are actually affected, since browsers sharing an engine tend to share rendering quirks and bugs too.
Chrome's User-Agent string "freezing" and why UA strings increasingly look generic
Google Chrome has been gradually implementing what it calls User-Agent string "freezing" or reduction — deliberately locking down and genericizing several components of the User-Agent string it sends, rather than continuing to include the browser's exact, specific minor version number and increasingly granular platform details as it always used to. This is a direct, deliberate part of the broader industry shift toward User-Agent Client Hints, mentioned in this site's Device Information tool — as Chrome intentionally reveals less through the traditional User-Agent header specifically to reduce fingerprinting surface, sites that still depend on parsing precise version numbers or platform detail out of the raw User-Agent string are gradually finding that information becoming less granular and less reliable over time, which is a genuinely important trend to be aware of if your own tooling depends on User-Agent parsing for anything beyond broad, general browser identification.
How the "Mobile" token distinguishes phone from desktop User-Agents
Mobile browsers typically include a specific "Mobile" token within their User-Agent string (for example, appearing right after the platform information on Android Chrome), and this single token is what many responsive websites and analytics platforms historically used as a quick, practical signal to distinguish mobile visitors from desktop ones without needing full, detailed device parsing. It's worth understanding, though, that this signal reflects the browser's own reported mode rather than the physical device's actual screen size — a tablet in desktop-requesting mode, or a phone with "Request Desktop Site" toggled on, will report differently than its actual physical hardware might otherwise suggest, which is exactly why User-Agent-based device detection is considered a rough, general heuristic rather than a fully precise and dependable measurement of a visitor's actual physical device or screen dimensions.
How known crawlers and bots identify themselves in their User-Agent
Legitimate search engine crawlers and other well-behaved automated bots generally identify themselves clearly and honestly within their own distinct User-Agent string — Googlebot, Bingbot, and similar well-known crawlers all include their specific bot name directly, along with a URL where webmasters can learn more about that particular crawler and its documented, expected behavior. This kind of transparent self-identification is exactly what makes it possible for a site's robots.txt file and server-side logic to specifically recognize, permit, or restrict particular known crawlers by name. It's important to understand, though, that this is purely a voluntary, honor-system convention rather than any kind of technical enforcement mechanism — a malicious scraper can just as easily claim to be Googlebot in its own self-reported User-Agent string, which is exactly why legitimate verification of a crawler's real identity requires a proper reverse-DNS lookup on the actual originating IP address, not simply trusting whatever the User-Agent header happens to claim.
Limitations of this tool
This tool parses a User-Agent string using pattern-matching rules against known browser, engine, and OS signatures — it can correctly identify the vast majority of common, current, real-world User-Agent strings, but as covered above, a User-Agent can always be freely spoofed or manually overridden, so parsing results should never be treated as a verified, trustworthy fact for any actual security decision. It also can't parse a brand-new, genuinely unrecognized browser or a heavily customized User-Agent string it has no existing signature pattern for, and as browsers continue reducing what they reveal through this traditional header (as explained above), parsed results across the entire web may naturally become somewhat less detailed over time, independent of anything specific to this particular tool.