What Is Client Hints Fingerprinting and Why Does It Matter in 2026?
If you’ve been following browser privacy developments, you’ve likely heard about User-Agent Client Hints — the mechanism that replaced the traditional User-Agent string in Chrome and Chromium-based browsers. But what you may not realize is how client hints fingerprinting explained in technical detail reveals a new, more structured, and arguably more powerful method of tracking users across the web.
The traditional User-Agent string was a messy, legacy artifact — a single text blob containing browser name, version, operating system, and device information, all concatenated into an increasingly unwieldy format. Google’s solution was User-Agent Client Hints (UA-CH): a structured, opt-in system where websites request specific pieces of information through HTTP headers. In theory, this gives users more privacy by limiting what information is shared by default. In practice, it has created a new fingerprinting surface that is more reliable, more granular, and harder for privacy tools to spoof correctly.
This guide provides a comprehensive technical deep-dive into Client Hints fingerprinting — how the mechanism works, what data it exposes, how websites exploit it for tracking, and what antidetect browsers must do to handle it correctly. For a broader overview of browser fingerprinting techniques, start with our guide on browser fingerprint explained.
The Evolution from User-Agent Strings to Client Hints
Why the User-Agent String Was Replaced
For decades, the User-Agent HTTP header carried detailed information about the browser and operating system in a single string:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
This string had several problems:
- Passive fingerprinting: Every HTTP request sent this detailed information automatically, without the website needing to ask for it
- Frozen versioning: Browser vendors had to maintain backward compatibility, leading to increasingly absurd strings (Chrome’s UA still includes “Mozilla/5.0” and “Safari/537.36”)
- High entropy by default: The full OS version, platform architecture, and exact browser version were available to every website on every request
- No user consent mechanism: There was no way for browsers to limit what information was shared or to prompt users for permission
Google’s User-Agent Reduction initiative, which reached full implementation in Chrome 110 (February 2023) and has been further refined through 2026, replaced much of this passive information exposure with an active, structured request system.
How User-Agent Client Hints Work
Client Hints follow a request-response model. When a website wants detailed information about the browser, it must explicitly ask for it using specific HTTP response headers or the Accept-CH meta tag. The browser then decides whether to share the requested information, based on its privacy policies and user settings.
The process works in two phases:
- Server request: The server sends an
Accept-CHheader listing the hints it wants (e.g.,Accept-CH: Sec-CH-UA-Platform, Sec-CH-UA-Full-Version-List) - Client response: On subsequent requests, the browser includes the requested hints as HTTP headers (e.g.,
Sec-CH-UA-Platform: "Windows")
Additionally, websites can access Client Hints through JavaScript using the navigator.userAgentData API, which provides both synchronous access to low-entropy hints and asynchronous access to high-entropy hints via navigator.userAgentData.getHighEntropyValues().
Low-Entropy vs. High-Entropy Client Hints
Low-Entropy Hints (Always Available)
Low-entropy hints are sent by default on every request without the server needing to request them. They are considered low-risk for fingerprinting because they provide coarse-grained information shared by many users:
| Header | Description | Example Value | Entropy Level |
|---|---|---|---|
Sec-CH-UA |
Browser brand and major version list | "Chromium";v="127", "Not)A;Brand";v="99", "Google Chrome";v="127" |
Low |
Sec-CH-UA-Mobile |
Whether the device is mobile | ?0 (desktop) or ?1 (mobile) |
Very Low |
Sec-CH-UA-Platform |
Operating system name | "Windows", "macOS", "Linux" |
Low |
These three headers are sent with every navigation and subresource request. The Sec-CH-UA header is particularly interesting because it includes a “brand list” — an array of browser brands and their major versions. This brand list intentionally includes a “GREASE” (Generate Random Extensions And Sustain Extensibility) brand like "Not)A;Brand" to prevent sites from hardcoding expected values.
High-Entropy Hints (Requires Explicit Request)
High-entropy hints contain detailed information that could contribute to fingerprinting. They are only sent when the server explicitly requests them via the Accept-CH header, and the browser may prompt the user or apply privacy restrictions:
| Header | Description | Example Value | Fingerprinting Risk |
|---|---|---|---|
Sec-CH-UA-Arch |
CPU architecture | "x86", "arm" |
Medium |
Sec-CH-UA-Bitness |
CPU bitness | "64", "32" |
Medium |
Sec-CH-UA-Full-Version-List |
Full version of each brand | "Chromium";v="127.0.6533.72", "Google Chrome";v="127.0.6533.72" |
High |
Sec-CH-UA-Model |
Device model | "Pixel 7", "" (desktop) |
High (mobile) |
Sec-CH-UA-Platform-Version |
OS version | "15.0.0" (Windows 11), "14.5.0" (macOS) |
High |
Sec-CH-UA-WoW64 |
Windows 32-bit on 64-bit | ?0 or ?1 |
Medium |
Sec-CH-UA-Form-Factors |
Device form factor | "Desktop", "Tablet", "Mobile" |
Medium |
The critical insight is that while high-entropy hints require explicit server requests, most websites have implemented Accept-CH headers that request all available hints. Analytics platforms, advertising networks, and anti-fraud systems routinely request the full set, effectively negating the privacy benefit of the opt-in model.
How Websites Use Client Hints for Fingerprinting
Constructing a Client Hints Fingerprint
A sophisticated fingerprinting system combines multiple Client Hints values to create a unique identifier. While individual hints have low entropy (many users share the same OS or browser version), the combination of multiple hints creates surprisingly unique fingerprints:
Consider this example combination:
- Platform: Windows
- Platform Version: 15.0.0 (Windows 11 24H2)
- Architecture: x86
- Bitness: 64
- Full Version: Chrome 127.0.6533.72
- Mobile: false
- Brand List: Chromium 127, Google Chrome 127, Not)A;Brand 99
How Send.win Helps You Master Client Hints Fingerprinting Explained
Send.win makes Client Hints Fingerprinting Explained simple and secure with powerful browser isolation technology:
- Browser Isolation – Every tab runs in a sandboxed environment
- Cloud Sync – Access your sessions from any device
- Multi-Account Management – Manage unlimited accounts safely
- No Installation Required – Works instantly in your browser
- Affordable Pricing – Enterprise features without enterprise costs
Try Send.win Free – No Credit Card Required
Experience the power of browser isolation with our free demo:
- Instant Access – Start testing in seconds
- Full Features – Try all capabilities
- Secure – Bank-level encryption
- Cross-Platform – Works on desktop, mobile, tablet
- 14-Day Money-Back Guarantee
Ready to upgrade? View pricing plans starting at just $9/month.
This combination narrows the user pool significantly. When combined with other fingerprinting signals (screen resolution, timezone, installed fonts, WebGL renderer), Client Hints contribute to a fingerprint that is unique to fewer than 1 in 50,000 browsers — effectively identifying individual users. For more on how websites track users through these combined techniques, see our article on browser tracking methods.
The JavaScript API Surface
Beyond HTTP headers, websites access Client Hints through the navigator.userAgentData JavaScript API. This API provides two access levels:
Synchronous access (low-entropy):
// Always available, no permission needed
const brands = navigator.userAgentData.brands;
// [{brand: "Chromium", version: "127"}, {brand: "Google Chrome", version: "127"}, ...]
const mobile = navigator.userAgentData.mobile; // false
const platform = navigator.userAgentData.platform; // "Windows"
Asynchronous access (high-entropy):
// Requires explicit request — browser may restrict
const highEntropy = await navigator.userAgentData.getHighEntropyValues([
"architecture",
"bitness",
"fullVersionList",
"model",
"platformVersion",
"wow64",
"formFactors"
]);
// Returns: {architecture: "x86", bitness: "64", ...}
Fingerprinting scripts typically call getHighEntropyValues() with all available hint names, collecting as much information as the browser will provide. As of 2026, Chrome provides all requested values without user prompting for first-party contexts, making the “opt-in” privacy model largely theoretical.
Cross-Referencing Client Hints with the User-Agent String
One of the most powerful fingerprinting techniques involves cross-referencing Client Hints data with the traditional User-Agent string. Even though Chrome has reduced the UA string, it still contains some information, and the consistency (or inconsistency) between the two sources is itself a signal:
- Version consistency: The major version in the UA string should match the major version in
Sec-CH-UA - Platform consistency: The OS indicated in the UA string should match
Sec-CH-UA-Platform - Brand consistency: The browser name in the UA string should correspond to a brand in the
Sec-CH-UAbrand list - Architecture consistency: If the UA string indicates “Win64”,
Sec-CH-UA-Bitnessshould be “64” andSec-CH-UA-Archshould be “x86”
Anti-fraud systems specifically look for mismatches between these sources, as they indicate browser spoofing or manipulation — a strong signal of bot activity or antidetect browser usage. For a deeper analysis of detection through Client Hints, see our detailed guide on user agent client hints detection.
Privacy Implications of Client Hints
The Privacy Paradox
User-Agent Client Hints were designed to improve privacy by replacing the always-on, high-entropy User-Agent string with an opt-in system. In theory, this should reduce passive fingerprinting — websites would only get the information they explicitly request, and browsers could limit what they share.
In practice, Client Hints have created a privacy paradox:
- More structured data: The structured format makes fingerprinting computationally easier — no need to parse a complex string, just read well-defined headers
- New data points: Client Hints expose information that wasn’t in the UA string at all, like CPU architecture and bitness
- Widespread opt-in: Nearly every website of significance requests all available hints, making the opt-in model meaningless
- Cross-validation: The existence of both the (reduced) UA string and Client Hints creates two data sources that can be cross-referenced for spoofing detection
- GREASE as fingerprint: Ironically, the randomized “Not a Brand” values intended to prevent hardcoding can themselves serve as temporal fingerprints, as the GREASE brand changes between browser versions
What Browsers Are Doing About It
Different browsers handle Client Hints differently, and these differences are themselves a fingerprinting signal:
| Browser | Client Hints Support | Low-Entropy Hints | High-Entropy Hints | Privacy Approach |
|---|---|---|---|---|
| Chrome | Full | Sent by default | Available on request | Selective restriction in third-party contexts |
| Edge | Full | Sent by default | Available on request | Follows Chrome’s implementation |
| Brave | Partial | Randomized/reduced | Restricted | Aggressive fingerprinting protection |
| Firefox | Partial (2026) | Limited implementation | Restricted | Participates reluctantly, plans to limit |
| Safari | No | Not sent | Not supported | Refuses to implement, uses ITP instead |
Safari’s refusal to implement Client Hints is notable — Apple has explicitly stated that the mechanism introduces new fingerprinting surface and that their Intelligent Tracking Prevention (ITP) approach is more privacy-protective. Firefox has gradually adopted a limited subset of Client Hints for compatibility reasons, but restricts high-entropy hints more aggressively than Chrome.
How Antidetect Browsers Must Handle Client Hints
The Spoofing Challenge
For antidetect browsers — tools designed to manage multiple browser identities without detection — Client Hints represent a significant technical challenge. It’s no longer sufficient to simply swap the User-Agent string. A properly spoofed browser identity must maintain perfect consistency across all of these surfaces:
- HTTP headers:
Sec-CH-UA,Sec-CH-UA-Platform,Sec-CH-UA-Full-Version-List,Sec-CH-UA-Arch,Sec-CH-UA-Bitness,Sec-CH-UA-Model,Sec-CH-UA-Platform-Version,Sec-CH-UA-Mobile - JavaScript API:
navigator.userAgentData.brands,navigator.userAgentData.mobile,navigator.userAgentData.platform, andnavigator.userAgentData.getHighEntropyValues() - User-Agent string: The traditional
navigator.userAgentheader and JavaScript property - Navigator properties:
navigator.platform,navigator.appVersion, and other legacy properties - GREASE brand: The randomized brand entry must match what the spoofed Chrome version would actually generate
Common Spoofing Mistakes
Many antidetect browsers and browser automation tools make detectable errors when spoofing Client Hints:
| Mistake | What Detectors Look For | Detection Impact |
|---|---|---|
| Spoofing UA string but not Client Hints | Chrome version in UA ≠ version in Sec-CH-UA | Immediate detection |
| Wrong GREASE brand format | Brand string doesn’t match Chrome’s GREASE pattern for that version | High confidence detection |
| Missing brand list entries | Real Chrome sends 3 brands; spoofed browser sends 2 | High confidence detection |
| Inconsistent platform across APIs | HTTP header says “Windows” but navigator.platform says “MacIntel” | Immediate detection |
| Static GREASE across sessions | Same GREASE value across all profiles (should vary) | Medium confidence detection |
| Wrong platform version mapping | “Windows” platform with macOS version format | High confidence detection |
| Returning hints without server request | High-entropy hints present in first request before Accept-CH is received | Medium confidence detection |
What Proper Client Hints Spoofing Requires
A properly implemented antidetect browser must:
- Maintain a version database: Map Chrome versions to their correct GREASE brands, brand list formats, and associated platform versions
- Synchronize all surfaces: HTTP headers, JavaScript API, User-Agent string, and navigator properties must all report consistent information
- Handle the Accept-CH flow correctly: High-entropy hints should only appear after the server requests them, not before
- Generate valid GREASE brands: The “Not a Brand” placeholder must use the correct format for the spoofed Chrome version (the punctuation character in the brand name varies by version)
- Support per-profile configurations: Each browser profile must have its own consistent set of Client Hints values that match its spoofed identity
Chrome’s Client Hints Implementation in Detail
The Sec-CH-UA Brand List Format
Chrome’s brand list is one of the most technically nuanced aspects of Client Hints. Each Chrome version generates a specific brand list with a deterministic GREASE entry. The format follows this pattern:
// Chrome 127 example:
"Not)A;Brand";v="99", "Chromium";v="127", "Google Chrome";v="127"
// Chrome 126 example:
"Not/A)Brand";v="8", "Chromium";v="126", "Google Chrome";v="126"
// Chrome 125 example:
"Google Chrome";v="125", "Chromium";v="125", "Not:A-Brand";v="24"
Notice that the order of brands, the GREASE brand string, and the GREASE version number all change between Chrome versions. This is intentional — Chrome uses a deterministic algorithm based on the major version number to generate these values. Any antidetect browser that claims to be Chrome 127 but sends the GREASE brand from Chrome 125 will be immediately flagged.
Platform Version Mapping
The Sec-CH-UA-Platform-Version header reveals OS version information, but the mapping between reported values and actual OS versions is not always intuitive:
| Reported Platform Version | Actual OS | Notes |
|---|---|---|
"1.0.0" to "10.0.0" |
Windows 10 | Maps to specific Windows 10 builds |
"13.0.0" to "15.0.0" |
Windows 11 | Maps to Windows 11 versions (22H2, 23H2, 24H2) |
"14.5.0" |
macOS Sonoma 14.5 | Direct mapping to macOS version |
"6.1" |
Linux | Kernel version (varies by distribution) |
"17.0" |
Android 17 | SDK version |
Spoofing a Windows platform with a macOS-formatted version string, or vice versa, is a detectable inconsistency that anti-fraud systems actively check for.
Third-Party Context Restrictions
Chrome restricts Client Hints in third-party contexts (cross-origin iframes and subresource requests) differently than first-party contexts. In third-party contexts:
- Only low-entropy hints are sent by default
- High-entropy hints require both the
Accept-CHheader and aPermissions-Policydelegation from the embedding page - In Chrome 127+, some high-entropy hints are completely blocked in third-party contexts regardless of permissions
This restriction creates another detection vector: if an antidetect browser provides high-entropy hints in a third-party context where a real Chrome browser wouldn’t, the inconsistency is detectable.
Defending Against Client Hints Fingerprinting
For Privacy-Conscious Users
Individual users can take several steps to reduce their Client Hints fingerprint:
- Use browsers that restrict Client Hints: Safari doesn’t support them at all; Brave aggressively randomizes them; Firefox limits high-entropy access
- Disable JavaScript for sensitive browsing: This prevents the
navigator.userAgentDataAPI from being accessed, though HTTP headers are still sent - Use browser extensions: Some privacy extensions can modify or block Client Hints headers, though this can create detectable inconsistencies
- Prefer Tor Browser: Tor normalizes all browser characteristics across users, including Client Hints responses
For Multi-Account Professionals
Users managing multiple browser profiles for legitimate business purposes — social media management, e-commerce operations, ad verification — need Client Hints to be spoofed correctly across all profiles. This is where antidetect browsers become essential, but the quality of Client Hints handling varies dramatically between tools.
How websites track users beyond traditional cookies is explained in depth in our guide on tracking without cookies, which covers Client Hints alongside other cookieless tracking vectors.
The Future of Client Hints and Fingerprinting
Emerging Developments in 2026
Several developments are shaping the Client Hints landscape:
- Client Hints reliability hints: Chrome is experimenting with “reliability” signals that indicate whether Client Hints values have been modified, adding another layer of integrity checking
- Network Client Hints: New hints like
Sec-CH-UA-Prefers-Color-SchemeandSec-CH-DPR(device pixel ratio) expand the available fingerprinting surface - Privacy Sandbox integration: Client Hints are being integrated with Chrome’s Privacy Sandbox APIs, creating new interaction patterns between attribution, topics, and browser identity
- Standardization pressure: W3C discussions continue about whether to standardize Client Hints across all browsers or allow the current fragmented approach to continue
What This Means for the Industry
Client Hints fingerprinting is not going away. If anything, the amount of information available through this channel will increase as new hints are added. For privacy-focused users and multi-account professionals, the implications are clear:
- Simply modifying the User-Agent string is no longer sufficient for identity separation
- Client Hints consistency across all browser surfaces is a critical requirement for any privacy or antidetect tool
- The bar for undetectable browser identity management continues to rise with each Chrome release
- Solutions that handle Client Hints at the browser engine level, rather than through extensions or proxies, will be the only reliable option
🏆 Send.win Verdict
Client Hints fingerprinting has fundamentally changed what it takes to maintain separate browser identities. Swapping the User-Agent string alone is a recipe for instant detection in 2026. Send.win handles Client Hints at the cloud browser level — every profile generates fully consistent Sec-CH-UA headers, navigator.userAgentData API responses, and GREASE brand entries that match the exact Chrome version being emulated. Because Send.win runs real browser instances in the cloud rather than patching a local browser, there are no detectable inconsistencies between HTTP-level and JavaScript-level Client Hints surfaces.
Try Send.win free today — manage multiple browser identities with perfect Client Hints consistency across every profile.
Frequently Asked Questions
What are User-Agent Client Hints?
User-Agent Client Hints (UA-CH) are a structured set of HTTP headers and JavaScript APIs that replaced the traditional User-Agent string in Chrome and Chromium-based browsers. Instead of sending all browser and OS information in a single string with every request, Client Hints allow websites to request specific pieces of information (like platform, architecture, or full version) through the Accept-CH header. The browser then responds with only the requested data via Sec-CH-UA prefixed headers.
What is the difference between low-entropy and high-entropy Client Hints?
Low-entropy hints (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform) are sent automatically with every request and contain coarse information shared by many users. High-entropy hints (Sec-CH-UA-Full-Version-List, Sec-CH-UA-Arch, Sec-CH-UA-Bitness, Sec-CH-UA-Platform-Version, Sec-CH-UA-Model) contain detailed information that could contribute to fingerprinting and are only sent when explicitly requested by the server via the Accept-CH header. However, most major websites request all available hints, effectively making them always available.
Can Client Hints be used to uniquely identify users?
Individually, Client Hints values have low entropy — millions of users share the same browser version and OS. However, when combined (platform + version + architecture + bitness + full version list + brand list), they create a substantially more unique fingerprint. Combined with other fingerprinting signals like screen resolution, timezone, fonts, and WebGL renderer, Client Hints contribute to fingerprints that can identify individual users with high confidence.
Do all browsers support Client Hints?
No. As of 2026, Chrome and Chromium-based browsers (Edge, Opera, Brave) support Client Hints, though Brave significantly restricts and randomizes them. Firefox has implemented partial support with aggressive restrictions on high-entropy hints. Safari explicitly refuses to implement Client Hints, citing fingerprinting concerns. This fragmented adoption means that which hints a browser supports is itself a fingerprinting signal.
How do antidetect browsers handle Client Hints spoofing?
Quality antidetect browsers must maintain perfect consistency across all Client Hints surfaces — HTTP headers, the navigator.userAgentData JavaScript API, the traditional User-Agent string, and legacy navigator properties. This includes generating the correct GREASE brand format for the spoofed Chrome version, mapping platform versions correctly, and respecting the Accept-CH flow where high-entropy hints are only sent after being requested. Poor implementations that only modify the UA string while leaving Client Hints unchanged are immediately detectable.
What is the GREASE brand in Sec-CH-UA?
GREASE (Generate Random Extensions And Sustain Extensibility) is a mechanism where Chrome includes a fake brand entry in the Sec-CH-UA brand list with random punctuation and a meaningless version number. For example, "Not)A;Brand";v="99". This prevents websites from hardcoding expected brand lists and ensures that new browsers can be added without breaking sites. The specific GREASE brand string is deterministically generated from the Chrome major version number, meaning it changes with each Chrome release.
Will Client Hints replace cookies for tracking?
Client Hints won’t directly replace cookies, but they are part of a broader shift toward cookieless tracking. As third-party cookies continue to be restricted, fingerprinting techniques including Client Hints become more valuable to trackers. Unlike cookies, Client Hints cannot be easily cleared by users, don’t expire, and are available even in private browsing mode. They serve as one component of a larger fingerprinting toolkit that includes canvas fingerprinting, WebGL fingerprinting, audio fingerprinting, and more.
How can I check what Client Hints my browser is sending?
You can check your Client Hints in several ways: (1) Open Chrome DevTools, go to the Network tab, click on any request, and look for Sec-CH-UA headers in the Request Headers section. (2) In the browser console, run navigator.userAgentData.brands to see low-entropy data, or await navigator.userAgentData.getHighEntropyValues(["architecture","bitness","fullVersionList","model","platformVersion"]) for high-entropy data. (3) Visit fingerprinting test sites like browserleaks.com or amiunique.org that display all Client Hints values your browser is sending.