User Agent Parser

The HTTP User-Agent header was introduced in 1992 to let servers identify the browser making a request. Thirty-four years later it is still sent by every major browser, but the string itself has accreted so many compatibility layers that modern UAs read like an archaeological dig. Today's Chrome on Windows sends Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 — claiming to be Mozilla, then claiming to be AppleWebKit, then claiming to be like Gecko, then finally identifying as Chrome at the end. None of these are lies in a deep technical sense; they are historical compatibility hacks layered on top of each other for thirty years.

Why parsing is unreliable

The strings have no formal grammar. Every browser invented its own format, then copied bits from competitors to dodge user-agent sniffing rules. The result is that any UA parser is a collection of heuristics, not a parser in the formal sense. The major libraries (ua-parser-js, ua-parser-rs) maintain regex tables that are updated frequently as new browsers and devices ship. The tool above uses a slimmer regex set covering the top ~95% of real-world traffic — Chrome, Safari, Firefox, Edge, Opera, Samsung Internet, UC Browser, plus the major search and SEO bots. For 100% accuracy you'd need a full ua-parser-js install, which we plan to wire in via Vite-bundled JS in a future update.

The Sec-CH-UA replacement (Client Hints)

Google has been deprecating UA strings since 2022, replacing the information they convey with HTTP Client Hints — a set of structured headers like Sec-CH-UA-Platform: "Windows" and Sec-CH-UA-Mobile: ?1. These are easier to parse (no string-mangling) and let browsers volunteer only the information the server actually requests. Chrome already sends a reduced UA string by default, with the full version available only via Client Hints. Firefox and Safari have not adopted Client Hints, so for the foreseeable future you need both UA parsing and Client Hint reading.

Browser distribution in Southeast Asia

One regional quirk worth knowing: Southeast Asia, particularly Malaysia, Indonesia, and Vietnam, has historically had a much higher share of UC Browser (Alibaba-owned, optimised for slow networks) than the global average. As of 2026 the share is declining as Android phones get faster and Chrome ships pre-installed on most devices, but UC Browser still represents 2-4% of mobile traffic in those markets — far higher than its sub-1% global share. Singapore is the regional outlier with browser distribution closer to North America (Chrome 70%, Safari 22%, Edge 5%, Firefox 2%). Bulk-parsing access logs from ASEAN sites with this tool will surface the regional UC Browser traffic that generic global parsers sometimes miss.

Don't sniff UAs for feature detection

The most-common UA-parser misuse is feature detection — checking the UA string to decide whether the browser supports a feature, then enabling or disabling code on that basis. Don't. Use feature detection (if ('IntersectionObserver' in window)) which actually checks whether the feature is available, instead of inferring it from a string that can be spoofed and that lies for compatibility reasons. UA parsing is appropriate for analytics ("what browsers visit my site"), bot detection ("is this a search crawler"), and content variation ("show iOS users the App Store link") — not for deciding whether to call a JavaScript API.