Look at the User-Agent string of a modern Chrome browser and you'll see something like "Mozilla/5.0 ... AppleWebKit/537.36 ... Chrome/120.0 Safari/537.36" — a string packed with references to browsers Chrome actually isn't. That's the result of decades of historical workarounds, not an accident.
The origin of "Mozilla"
In the 1990s, sites detected browser capabilities by checking whether the User-Agent contained "Mozilla" (the codename for Netscape Navigator, then the market leader). When Internet Explorer wanted the same "advanced" content, it started adding "Mozilla" to its own User-Agent too — and the precedent stuck for good.
Why Chrome contains "Safari"
Chrome is built on WebKit, the engine originally developed by Apple for Safari. Sites checked for "Safari" in the User-Agent to detect WebKit feature support, so Chrome added the word to keep those checks working — even though Chrome moved to its own Blink fork of the engine years ago. It's the same compatibility-by-imitation pattern that put "Mozilla" everywhere.
A market where "Mobile Safari" actually matters
In much of the world Android and Chrome dominate mobile traffic by a wide margin, but the US and UK are unusual: iPhone adoption there is high enough that "Mobile Safari" in the User-Agent shows up in a substantial share of mobile hits, not just a niche one. That's one reason browser-detection code written by US or UK teams sometimes under-tests Android/Chrome edge cases — the traffic split they see day to day skews further toward iOS than the global average.
Why User-Agent detection is unreliable
Because every new browser tacks its predecessors' tokens onto the User-Agent for compatibility, the string has become a pile of historical artifacts rather than an accurate description of the browser. Current best practice is to feature-detect specific JavaScript or CSS capabilities directly instead of parsing the User-Agent.
What this is useful for
- Diagnose compatibility issues by inspecting exactly which browser and version a client reports.
- Make sense of server logs where visitor User-Agent strings are recorded.
- Understand why old User-Agent-based browser-detection code so often gets it wrong.
User-Agent Client Hints as a replacement
Instead of parsing one bloated string, Chromium-based browsers now support User-Agent Client Hints — separate headers like Sec-CH-UA, Sec-CH-UA-Platform, and Sec-CH-UA-Mobile that a server must explicitly request and receives in structured form. It's part of a broader "User-Agent Reduction" push for privacy, meaning the classic User-Agent string will carry fewer and fewer details over time.