Sec-CH-UA high-entropy hints
User-Agent Client Hints separate coarse, default hints from high-entropy ones — full browser version list, platform version, architecture, bitness, and device model — that browsers do not send unless a site explicitly requests them via Accept-CH. They carry more identifying detail, so the browser can decline, and they should be requested only when genuinely needed.
What this means
Client Hints split into low-entropy hints (browser brand list, Mobile, Platform) that are sent by default, and high-entropy hints that are not. The high-entropy set includes the full version list, platform version, CPU architecture, bitness, and device model — details that, combined, are more distinctive.
Because of that, the browser only sends them when a site asks, and it may decline even then. This opt-in model is deliberate: get coarse context for free, request fine detail explicitly, and accept that you may not receive it.
Requesting them with Accept-CH
A server signals which hints it wants by listing them in an Accept-CH response header. On subsequent requests, a supporting browser may include the requested high-entropy hints. There is also a delegation mechanism so embedded content can receive hints, and a way to persist the request across navigations.
Request only what you genuinely need. Asking for the full set on every request maximises fingerprinting surface for little benefit, and graceful handling of withheld hints is required because the browser is free to decline.
- Examples: Sec-CH-UA-Full-Version-List, -Platform-Version, -Arch, -Bitness, -Model
- Not sent by default — request via Accept-CH
- The browser may still decline; degrade gracefully
Using them responsibly
There are legitimate reasons to request a high-entropy hint — serving a precise binary for an OS/architecture pair, or working around a known platform-version bug. In those cases, request the single hint you need and use it for that purpose only.
What to avoid is collecting many high-entropy hints and stitching them with other signals into a stable identifier. That is fingerprinting, which the Client Hints design is meant to make a conscious, visible choice rather than a silent default.
How it appears in analytics and logs
The presence of headers like Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform-Version, Sec-CH-UA-Arch, or Sec-CH-UA-Model means a site requested high-entropy hints and a Chromium browser chose to send them. Their absence is normal — they are opt-in.
Diagnostic use case
Understand which Client Hints are high-entropy, how to request them with Accept-CH, and why to request the minimum needed rather than everything.
What WebmasterID can help detect
Knowing these hints are opt-in clarifies why WebmasterID does not depend on them: it reads coarse, low-entropy context rather than requesting high-entropy detail that browsers may withhold.
Common mistakes
- Expecting high-entropy hints without requesting them via Accept-CH.
- Requesting the full set when one specific hint would do.
- Combining high-entropy hints into a stable identifier (fingerprinting).
Privacy and accuracy notes
High-entropy hints carry more identifying detail, so requesting and combining many of them increases fingerprinting surface. WebmasterID stays at coarse, low-entropy context and does not assemble these into identifiers.
Frequently asked questions
- Why am I not receiving Sec-CH-UA-Platform-Version?
- It is a high-entropy hint, not sent by default. You must request it with an Accept-CH response header, and even then a supporting browser may decline to send it.
Related pages
- Sec-CH-UA-Platform and Sec-CH-UA-Mobile
Sec-CH-UA-Platform and Sec-CH-UA-Mobile are User-Agent Client Hint request headers. Platform reports the operating-system family (such as Windows, macOS, or Android) and Mobile is a boolean for whether the client is a mobile device. Both are low-entropy hints sent by default in supporting Chromium browsers, offering coarse context without parsing the legacy user agent.
- User-Agent Client Hints
User-Agent Client Hints are HTTP headers (the Sec-CH-UA family) that let a site request specific browser, platform, and version detail rather than reading it all from one passive string. They underpin UA reduction: the raw user agent is shrinking, and finer detail moves to opt-in hints. This page explains the model.
- User agent entropy and privacy
The user-agent string packs many details — browser, version, OS, device — whose combination adds entropy that contributes to browser fingerprinting. To reduce passive tracking, browsers freeze and reduce the user agent and move high-entropy detail behind explicitly requested Client Hints. Coarse use stays privacy-safe; aggregating detail to identify users does not.
- Privacy-first analytics
Coarse, low-entropy context with no fingerprinting.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.