ゆるテックノート

The long, layered browser UA string

Browser User-Agent strings carry decades of compatibility labels. They started as a way to look compatible; now browsers aim to shrink them for privacy and stability.

A stack of history

Servers used UA strings to branch behavior, so browsers kept adding badges to look compatible.

Key layers

  • Mozilla: legacy from Netscape Navigator; many browsers kept it to avoid being blocked.
  • Gecko: the Firefox engine name, but the phrase “like Gecko” in another browser does not mean it uses Gecko.
  • KHTML / AppleWebKit: historical engine labels. Chrome retains AppleWebKit even when using Blink, so the token alone does not identify the current engine.
  • Chrome / Safari / Edg: brand names coexist with compatibility labels. Desktop Edge uses Edg/, while mobile variants include EdgA/ and EdgiOS/.

Example Chrome UA

Version 123 illustrates the format, not the current release. The Safari token does not make this example Safari.

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

Why so many tokens?

UA sniffing was common, so browsers signaled “I am compatible” by reusing others’ labels.

Past reasons

  • Early Web compatibility differed greatly across browsers; servers branched on UA.
  • Missing a familiar token could trigger “unsupported” blocks, so vendors kept piling on tokens.

Modern risks

  • UA strings are long and leak device/OS details, increasing fingerprintability.
  • UA-based branching is brittle and can break new browsers or features.

UA Reduction & Client Hints

UA reduction freezes or reduces detailed device and OS information; it is not simply about making the string shorter. Browser policies and available information differ.

User-Agent Reduction

  • Chrome rolled out UA reduction for desktop and Android in 2023. Frozen values such as Windows NT 10.0 do not precisely identify the actual OS version.
  • Do not assume Safari or Firefox exposes the same UA format or Client Hints as Chrome. Provide a working path without UA-CH.

User-Agent Client Hints

  • Supporting browsers expose structured information over HTTPS. Chromium sends basic hints such as Sec-CH-UA, Sec-CH-UA-Mobile, and Sec-CH-UA-Platform without Accept-CH.
  • Accept-CH requests additional hints, but browser support and policy can leave them unavailable. Brand lists can contain unknown brands in varying order; the first item is not necessarily the product name.
  • Requesting detailed data increases identifying information. Use only what is needed, and never treat UA or Client Hints as authentication or authorization evidence.

Practical guidance

Detect the required capability instead of inferring it from UA. Values can be altered or spoofed, so a UA string is not a trusted identity.

Recommended approaches

  • Use feature detection on the front end; reserve UA sniffing as a last resort.
  • For analytics, do not fill missing data with guesses; collect only information needed for the purpose.
  • Review existing UA branches and combine feature detection with testing in target browsers.

Official sources and related reading

Chromium: UA Reduction / Chrome: UA Client Hints / UA-CH specification / Edge UA guidance / MDN: UA sniffing
Browsers and Web standards / DNS root servers

< Who runs the Web? Shared vs vendor-specific browser features >