Fast, practical, browser-based developer tools
Parse user-agent strings to identify browser family, operating system, rendering engine, device type, and raw user-agent details instantly. This tool is useful for debugging, logging analysis, QA investigation, and browser support checks.
User-agent strings appear in analytics, logs, support tickets, bug reports, and client-side diagnostics. This parser helps you quickly understand which browser, operating system, device type, and rendering engine a request may be using.
User-agent parsing is useful when reviewing access logs, investigating browser-specific issues, validating client environments, or checking what kind of device a request likely came from.
For more details about site usage and analytics, read our Privacy Policy.
Paste a user-agent string into the input field or load your current browser’s user-agent automatically, then run the parser to inspect the detected browser, OS, device type, and rendering engine.
Browser: Google Chrome OS: Windows 10/11 Device: Desktop Engine: WebKit/Blink
Read a modern User-Agent string and it appears to claim several browsers at once. A current
Chrome sends something like
Mozilla/5.0 ... AppleWebKit/537.36 (KHTML, like Gecko) Chrome/xxx Safari/537.36
— announcing Mozilla, KHTML, and Safari while actually being none of them. This is not a
bug; it is thirty years of accreted compatibility lies, each one added to get past servers
that sniffed the UA string and served a degraded page otherwise.
The chain of history: Netscape called itself Mozilla, and sites checked for
“Mozilla” before sending rich pages, so Internet Explorer also claimed to be
“Mozilla (compatible; MSIE...)”. Everyone then copied everyone: Safari claimed
KHTML (its engine's ancestor) “like Gecko”; Chrome claimed both Safari and KHTML
to inherit their working code paths; Edge, now on Chromium, appends its own token but keeps
Chrome and Safari so sites treating it as Chrome behave. The token
soup exists because removing any single lie risked some old server serving a broken page.
Because the string is a compatibility fiction, using it to decide what a browser can do is fragile and routinely wrong. Version numbers get spoofed, in-app webviews and privacy modes freeze or fake the UA, and a regex keyed on “Safari” will match Chrome, which also claims Safari. UA sniffing is also how sites accidentally lock out new browsers: an unrecognised string falls through to a “please upgrade” branch even though the browser is perfectly capable.
The robust alternative is feature detection: ask directly whether a
capability exists — 'IntersectionObserver' in window,
CSS.supports('display: grid'),
typeof navigator.share === 'function' — and branch on the answer. It cannot
be faked into a wrong result the way a UA string can, and it keeps working for browsers that
didn't exist when you wrote the code. Reserve UA parsing for coarse analytics and support
diagnostics, not runtime decisions.
The industry is actively retiring the UA string. Chromium's User-Agent
reduction deliberately freezes and trims it — capping the version detail and
normalising the platform — so it leaks less and can't be relied on for fine-grained
detection. In its place come User-Agent Client Hints: structured values a
server can request, such as Sec-CH-UA, Sec-CH-UA-Platform, and
Sec-CH-UA-Mobile, or read in JavaScript through
navigator.userAgentData.
The shift matters for two reasons. High-entropy details like the full platform version are no longer volunteered by default — a server has to ask for them, which makes passive fingerprinting harder. And the data arrives already parsed into fields, so you stop reverse-engineering a string with brittle regexes. Any UA parsing you rely on today should be treated as a fallback that will return progressively less detail over time.
Even without cookies, the UA string contributes to a browser fingerprint. On its own it is coarse, but combined with your language, timezone, screen size, installed fonts, and graphics quirks it helps single out one browser among millions. A rare or heavily customised UA makes you more identifiable, not less — one reason privacy-focused browsers standardise their UA so users blend together, and part of why the platform is moving to Client Hints that reveal detail only on request.
This parser runs entirely in your browser. The string it reads is your own
navigator.userAgent, or whatever you paste in, and the parsing happens in local
JavaScript — nothing is sent to a server. That is why it works offline, and why pasting
an arbitrary UA string is safe: you are only running text through a local pattern match.
If you must parse a UA string, read the right tokens. The rendering engine
is more reliable than the browser name: AppleWebKit/Blink underlies
Chrome, Edge, and most Chromium browsers, Gecko is Firefox, and only Safari
pairs WebKit with no Chromium token. Because Chrome, Edge, Opera, Brave, and Samsung Internet
all carry Chrome/, the distinguishing token is the vendor suffix
(Edg/, OPR/, SamsungBrowser/) that appears
after it — miss that and you will label them all as Chrome.
Two more practical notes. The literal token Mobile (present in mobile Safari and
Chrome) is a more honest mobile signal than trying to read a device model. And many of the
highest-traffic user-agents are not browsers at all: Googlebot,
bingbot, monitoring probes, and HTTP libraries like curl and
python-requests all identify themselves here — which is why a UA parser is
often more useful for classifying bots than for pinning down a human's browser.
Historical compatibility. Each browser copied the tokens sites already checked for, so every engine inherited the labels of its predecessors. Chrome claims Safari and KHTML “like Gecko,” and everyone still opens with “Mozilla/5.0,” purely to avoid old servers serving a degraded page.
No. The UA string is spoofable, frozen, and full of misleading tokens, so keying features
off it breaks constantly. Use feature detection instead — test for the capability
directly (for example CSS.supports(...) or
'IntersectionObserver' in window), which can't be faked wrong.
They are the modern replacement for the UA string: structured, opt-in values
(Sec-CH-UA, platform, mobile flag) a server requests or JavaScript reads via
navigator.userAgentData. They give you parsed fields instead of a string to
regex, and reveal high-entropy detail only when asked.
No. A user-agent can be changed, frozen, or faked — webviews and privacy tools routinely do — and User-Agent reduction is deliberately trimming the detail available. Treat parsed browser and OS values as a best-effort reading of a string that is designed to be imprecise.
No. It reads navigator.userAgent (or the text you paste) and parses it in
local JavaScript in your browser. Nothing is uploaded, which is why it works offline and
why testing an arbitrary UA string is safe.
Partly. On its own it is coarse, but it feeds a browser fingerprint alongside your timezone, language, screen, and fonts. An unusual or heavily customised user-agent makes you easier to single out — blending in is what reduces trackability, which is one reason the UA is being reduced.