Websites sometimes need to know which browser or device is visiting. A download page may offer the correct installer, a service may avoid a known browser bug, and a layout may adapt to mobile hardware. For decades, much of that information arrived in one long User-Agent string sent with nearly every request.
User-Agent Client Hints aim to replace that all-at-once disclosure with smaller pieces. Some broad details can be available by default, while more specific values are requested only when a server says it needs them and the browser chooses to provide them.
Why the old User-Agent string became a problem
The traditional header grew into a complicated mixture of browser names, engine tokens, operating-system details, device markers, and compatibility phrases. Sites learned to parse it instead of testing whether a feature actually worked. Browsers then copied one another's tokens to avoid being rejected by brittle detection code.
The result was poor accuracy and unnecessary passive fingerprinting surface. A server could receive detailed device information before the page ran any code and without asking for a particular field. User-Agent reduction makes the legacy string less specific, while Client Hints provide a structured route for information that a site genuinely needs.
What low-entropy hints reveal
Supporting browsers can send a small default set of headers such as Sec-CH-UA, Sec-CH-UA-Mobile, and Sec-CH-UA-Platform. These communicate broad browser branding and major version, whether the browser considers the device mobile, and a general platform category.
MDN describes Sec-CH-UA as a low-entropy hint. Its brand list may include intentionally unfamiliar or synthetic entries. That design discourages servers from assuming that only a fixed list of browser names is valid.
Low entropy does not mean zero information. The values still help a server classify the browser. The goal is to keep the default set broad enough that many users share the same pattern and to avoid exposing full device detail everywhere.
How a site requests more detail
A server can return an Accept-CH response header naming the hints it wants. On later requests to that origin, the browser may attach approved values. Examples include the full browser version, operating-system version, device model, architecture, or form factor.
The MDN Client Hints guide separates low- and high-entropy hints. High-entropy values have greater potential to distinguish a device, so the user agent has more reason to restrict them according to its policy, settings, and the requesting context.
JavaScript can also access low-detail values through navigator.userAgentData. A page can call getHighEntropyValues() with a list of requested fields. The word “high” describes fingerprinting potential, not guaranteed uniqueness or sensitivity in every situation.
Why the first request matters
A server cannot normally receive an opt-in high-entropy hint until it has first replied with Accept-CH. This creates a sequence: the initial request carries default information, the response asks for selected hints, and subsequent requests may include them.
There are reliability mechanisms for cases where a hint must affect the first useful response, but developers should avoid treating detailed device detection as essential. Feature detection and responsive design often produce more robust results without classifying the visitor's exact browser build.
Our article on what browsers send before a page loads explains why default request headers are considered passive signals. Client Hints try to reduce that default disclosure, even though they do not remove it entirely.
Can Client Hints be used for fingerprinting?
Yes, especially when a site obtains several detailed values and combines them with other characteristics. A model, architecture, platform version, screen behavior, language list, and time zone can narrow the crowd of matching devices.
The User-Agent Client Hints specification states that reducing default fingerprinting surface is a primary goal. It also allows a browser to return an empty value or refuse a hint. Secure-transport requirements and Permissions Policy integration limit some exposure, but no technical structure can make requested device information harmless in every combination.
See our browser fingerprinting guide for how multiple ordinary signals can become more identifying as a set.
Client Hints are not a permission prompt
Users should not expect a pop-up every time a site asks for a browser version or device architecture. “Opt in” in the protocol often means that the server declares interest and the browser applies its own delivery policy. It is not necessarily a per-site decision shown to the person.
This is different from camera, microphone, or precise-location access, where explicit prompts are common. Browser vendors can still reduce, freeze, omit, or standardize hint values as part of privacy protection.
Why developers should request less
Prefer capability checks
If a site needs to know whether an API or CSS feature exists, it should test that capability directly. Browser names and versions are imperfect proxies, especially when updates, forks, enterprise policies, and embedded browsers behave differently.
Request only actionable fields
A download page may need platform and architecture. It probably does not need a device model. Each extra field increases cache variation, implementation complexity, and fingerprinting surface. The best hint is one that changes a concrete response.
Keep third parties constrained
Detailed values should not automatically flow to every embedded frame or resource. Permissions Policy and careful server configuration can limit delegation. Request blocking adds another layer by preventing known trackers from collecting the surrounding signals.
What users can do
Keep the browser current, because privacy behavior and User-Agent reduction evolve with releases. Avoid extensions that spoof many values independently; an inconsistent combination can break sites or make the browser more distinctive. Use tracker blocking to limit the number of third parties able to combine hints with cookies and behavioral data.
Changing a visible browser name is not enough to disappear. IP addresses, account logins, storage, link identifiers, and active fingerprinting remain separate. Privacy comes from reducing unnecessary disclosure across the whole request and execution path.
From one long string to measured disclosure
User-Agent Client Hints are an attempt to make device adaptation more deliberate. Broad compatibility information can remain available, while finer detail is structured, requested, and subject to browser control. The system is not fingerprint-proof, and support differs between browser families. Its strongest principle is still useful: websites should receive the minimum device information needed for a specific job, not a detailed identity card with every visit.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.