User-Agent Parser

What is a User-Agent String?

A User-Agent is a header your browser attaches to every HTTP request. It is a single line of free-form text whose job is to tell the server what software is asking for the page. A typical modern example looks like this:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

Read it left to right and it is a list of product tokens, each optionally followed by a slash and a version, with comments in parentheses. In principle it identifies one browser. In practice, the example above names four different products — Mozilla, AppleWebKit, KHTML and Safari — none of which are actually running.

Why Every Browser Claims To Be Mozilla (And Safari, And KHTML)

This is the single strangest thing about User-Agent strings, and it is entirely the product of thirty years of accumulated compatibility hacks. Each layer was added because servers were sniffing for the previous one.

• Mozilla/ — Netscape Navigator called itself Mozilla in 1994. Sites started serving frames only to Mozilla. When Internet Explorer arrived it supported frames too, so it declared itself Mozilla/1.22 (compatible; MSIE 2.0; ...) to get the good content. Every browser since has kept the prefix. Today Mozilla/5.0 is a hardcoded constant that carries no information at all.
• KHTML, like Gecko — Apple built WebKit from KDE’s KHTML engine, and needed sites that sniffed for Gecko (Firefox) to serve it modern markup. So Safari claimed to be KHTML-based and Gecko-like simultaneously.
• Safari/ — when Chrome launched in 2008 it used WebKit, and sites were already sniffing for Safari to serve WebKit-friendly CSS. Chrome therefore appended Safari/537.36. Chrome switched to its own Blink engine in 2013 and kept the token anyway. It has been a lie for over a decade.
• Chrome/ in Edge and Opera — Microsoft Edge and Opera are Chromium browsers, so they include a Chrome/ token and append their own marker at the end: Edg/ and OPR/. Note that Edge uses Edg, deliberately without the trailing “e”, so that code sniffing for the old EdgeHTML-based “Edge” does not match.

The practical consequence for anyone writing a parser: detection order is everything. Check for Edg/, OPR/ and SamsungBrowser/ before Chrome, and check for Chrome before Safari. Get the order backwards and every Edge user in your analytics is silently counted as Chrome.

The Browsers That Are Not What They Say

On iOS and iPadOS, Apple’s App Store rules have historically required every browser to use the system WebKit engine. Chrome, Firefox, Edge and Opera on an iPhone are all WebKit under the hood — they are essentially skins over Safari with their own sync, UI and bookmarks. They signal themselves with distinct tokens:

• CriOS/ — Chrome on iOS (WebKit, not Blink)
• FxiOS/ — Firefox on iOS (WebKit, not Gecko)
• EdgiOS/ — Edge on iOS (WebKit, not Blink)
• OPiOS/ and OPT/ — Opera and Opera Touch on iOS

This matters far more than a logo in a dashboard. If a CSS feature or a JavaScript API is broken in Safari, it is broken in every browser on that device. A parser that reports “Chrome 126” for a CriOS string will send you hunting for a Blink bug that cannot exist. This tool reports the engine separately from the brand for exactly that reason.

Why UA Sniffing Is Discouraged

Branching your code on the User-Agent string is one of the oldest anti-patterns on the web. The string is trivially editable — every browser has a device-emulation mode, every HTTP client lets you set the header, and privacy extensions spoof it by default — so it is not a security control and it is not reliable telemetry. Worse, a UA check is a snapshot of the world on the day you wrote it. New browsers and new versions ship constantly, and code that says “if not Chrome, show the fallback” will keep punishing browsers that gained the feature years ago.

The recommended alternative is feature detection: ask the browser whether the thing you need actually works, rather than guessing from its name. Test the capability directly with checks like "IntersectionObserver" in window, CSS.supports("display", "grid"), or typeof navigator.share === "function". These stay correct forever, cannot be spoofed into the wrong answer, and work for browsers that did not exist when you shipped.

Legitimate uses for parsing a UA do remain: aggregate analytics, reproducing a bug from a support ticket, serving the right app store badge, filtering crawlers out of your logs, and rate-limiting abusive clients. Those are all after-the-fact reporting rather than runtime branching — which is exactly the right place for it.

Client Hints: The Replacement

Because the UA string leaks a lot of passively-collected entropy useful for fingerprinting, Chromium has been shrinking it under a programme called User-Agent Reduction. Desktop UA strings now report a frozen minor version, and Android strings report a frozen Android 10 with the device model masked as K — which is why a modern Pixel can show up as an anonymous Android 10 handset.

What replaces it is User-Agent Client Hints: the same information, but structured, requested explicitly, and split into low-entropy and high-entropy tiers. In JavaScript it is navigator.userAgentData, exposing brands, mobile and platform for free, and platform version, architecture, bitness, model and full browser version only via an async getHighEntropyValues() call. On the server, the same data arrives as Sec-CH-UA headers, and you must opt in with an Accept-CH response header before the high-entropy ones are sent.

The catch is adoption. Client Hints are Chromium-only — Firefox and Safari have both declined to implement them on fingerprinting grounds. So for the foreseeable future you need both: Client Hints where available, and a careful, correctly ordered UA parser everywhere else.

FAQ

Related Tools