Summary

  • Chromium's compatibility FAQ showed a Chrome string carrying Mozilla/5.0, AppleWebKit, Chrome and Safari labels together. It said sites that parsed User-Agent strings often failed to recognize Chrome and sometimes called it unsupported.
  • Chrome 11 changed some tokens in 2011 to align with other browsers. Chrome 110 began replacing Android version and model details with fixed values in 2023, while the inherited labels remained in the format. The field shed detail without shedding its compatibility history.

A name tag made of other people's names

The Chromium compatibility FAQ offered developers an example of Chrome's User-Agent string: Mozilla/5.0, then platform information, AppleWebKit, Chrome/2.0.167.0 and Safari/525.13. This was not four browsers running inside one window. It was one browser speaking in labels websites had learned to inspect. The FAQ said faulty JavaScript or server-side checks often failed to identify Chrome correctly; some pages told visitors Chrome was unsupported. Its advice was to test the browser's capabilities instead of guessing from a name.

A name check was cheaper for a site than testing every feature. It also turned the name into a contract. If a site dispatched one page to Safari, another to Chrome, and a third to anything beginning Mozilla, each token could change what the user received. A browser maker had to weigh truthful description against the code already waiting at the server.

Chrome deleted a false language, then kept the costume

In a 31 March 2011 announcement, Chromium compared Chrome 10 and 11 User-Agent strings. It removed an obsolete U token that once spoke to export-era encryption strength and dropped the locale token. The team said Chrome's locale value had always reported en-US because of a bug, whatever the user's desired languages; websites should consult Accept-Language instead. It also changed Windows tokens and said it was matching Firefox 4 promptly because websites used common parsers for many browsers. The team had already found compatibility failures in Google's own UA parsing libraries.

Yet the examples on both sides of that change still began with Mozilla/5.0 and included AppleWebKit, Chrome and Safari. The detailed tokens were negotiable. The inherited shape was harder to move. In RFC 9110, published in June 2022, the User-Agent field was still defined as product identifiers and comments useful for interoperability workarounds and analytics. The standard urged senders to limit unnecessary detail because a long, specific string could aid fingerprinting. It also discouraged borrowing another product's tokens just to declare compatibility. The standard described what the field was for; Chromium's examples showed the compatibility bargain browsers had already made.

Privacy won a few fields, not the whole string

Chrome's 2023 reduction notice said the browser would gradually replace the Android version and device model in the default string from Chrome 110. A phone running Android 13 on a named device could appear as Android 10 on model K. The stated aim was to reduce passive cross-site tracking. The before-and-after examples kept the overall format, including Mozilla/5.0, AppleWebKit, Chrome and Safari.

That is the history in miniature: a field meant to identify software became an input to site behavior, then a source of identifying detail to trim. Chrome could hide a phone model and keep the old masks because those masks were now part of the web's compatibility machinery. A dated measurement of site branching and pre- and post-reduction fingerprinting would show the scale of each effect. The original records show why the format survived even as its values changed.

Sources