Check Which Client Hints Your Browser Sends

Check Which Client Hints Your Browser Sends

Run the inspector above and it shows you the same Client Hints a server sees. In Chromium browsers, User-Agent Client Hints replace the User-Agent string with a structured API: the Sec-CH-UA request header and the navigator.userAgentData JavaScript API provide a structured, graduated alternative to the legacy User-Agent string. By default, every Chromium request includes three low-entropy hints: Sec-CH-UA with the browser brand and major version, Sec-CH-UA-Mobile indicating mobile or desktop, and Sec-CH-UA-Platform with the OS name.¹ These default hints expose less information than the legacy UA string, which included the full OS version and platform architecture.

Yet servers can request high-entropy values: platform version, CPU architecture, device model, and full browser version can be requested by including an Accept-CH response header, and scripts can also call navigator.userAgentData.getHighEntropyValues() directly to obtain the same data without a server round-trip.² Consequently, the privacy benefit of UA-CH depends entirely on which hints a server requests and whether the browser honors those requests without user awareness.

What low-entropy UA-CH hints expose automatically

The three default Client Hints, Sec-CH-UA, `Sec-CH-UA-Mobile, and Sec-CH-UA-Platform, are sent on every same-origin and cross-origin request from Chromium-based browsers without requiring any server permission. Sec-CH-UA` includes a JSON-encoded list of browser brands and their major versions: a typical value is '"Chromium";v="124", "Google Chrome";v="124", "Not-A.Brand";v="99".³ This list identifies the browser family and major version, which is slightly less entropy than the legacy UA that included the build version.

`Sec-CH-UA-Mobile is a boolean that returns ?1 for mobile browsers and ?0 for desktop, which narrows the device class. Sec-CH-UA-Platform returns the OS name as a string: "Windows", "macOS", "Android", "Linux". Consequently, a server can determine OS and browser family from these three default headers without any explicit permission request. Building on this, the "Not-A.Brand" entry in Sec-CH-UA` is a deliberate obfuscation to prevent brand-list-based browser detection from becoming too precise.³

High-entropy hints requiring explicit server permission

Servers that want more detailed browser information can request high-entropy Client Hints via the Accept-CH response header. Responding with "Accept-CH: `Sec-CH-UA-Arch, Sec-CH-UA-Platform-Version, Sec-CH-UA-Model" instructs the browser to send CPU architecture, OS platform version, and device model on subsequent requests to that origin. JavaScript scripts can call `navigator.userAgentData.getHighEntropyValues(['architecture', 'platformVersion', 'model', 'uaFullVersion']) to request the same information without a server round-trip.

How high-entropy hints restore what UA Reduction removed

The returned object contains values like platformVersion: "15.0", architecture: "x86", bitness: "64", and the full browser version including minor and patch numbers, which means a single Accept-CH header restores most of the entropy that UA Reduction removed from the legacy User-Agent string.⁴ Furthermore, the getHighEntropyValues() call returns a Promise rather than synchronous data, which means fingerprinting scripts must await the result, introducing a brief asynchronous step that separates Client Hints collection from synchronous canvas and WebGL fingerprinting. This permission model is what distinguishes Client Hints from the legacy UA string: the server must explicitly ask for high-entropy data rather than receiving it unconditionally on every request.

Testing the Client Hints row in CapyToolkit shows exactly which values your browser exposes and whether a site has requested the high-entropy set. The inspector displays the default low-entropy hints alongside any high-entropy values a server has triggered, so you can see how much extra detail an Accept-CH header adds. Comparing that output against Firefox or Safari, which send no Client Hints at all, shows how much of the surface is Chromium-specific.

Privacy implications for developers sending Accept-CH headers

From a developer perspective, Accept-CH is a straightforward way to recover the detailed browser version information that UA Reduction removed from the legacy User-Agent string. From a privacy perspective, requesting high-entropy hints through Accept-CH headers increases the browser fingerprint entropy of every user who visits the site beyond what the browser would normally expose. Each Accept-CH value requested adds an additional dimension to the fingerprint surface the server receives, and requesting all available high-entropy hints effectively restores the full entropy that UA Reduction was designed to eliminate.

How to use client hints responsibly

Consequently, developers who include Accept-CH headers for analytics or compatibility purposes are expanding their users' fingerprint exposure beyond what the browser's defaults provide. The W3C recommends that servers request only the hints they need for legitimate functionality rather than requesting all available values. Building on this, Firefox does not implement Client Hints at all; it continues to send the legacy User-Agent string and never sends Sec-CH-UA headers. Safari also does not send Client Hints.⁵ Therefore, Client Hints are a Chromium-specific fingerprinting surface, and servers that rely on them for compatibility detection receive no equivalent data from Firefox and Safari users. A narrow request list is usually the safest compromise between compatibility and privacy.

Auditing Accept-CH headers with browser DevTools

Auditing which high-entropy Client Hints a site requests takes less than a minute in Chrome DevTools. Open DevTools, navigate to the Network panel, reload the page, click the top-level document request, and examine the Response Headers tab. An Accept-CH header listing `Sec-CH-UA-Arch and Sec-CH-UA-Platform-Version means the server will receive your CPU architecture and exact OS version on all subsequent requests to that origin. The Permissions-Policy` header on the same response may also grant cross-origin subframes permission to request hints, extending the data collection to third-party analytics or advertising scripts embedded in the page.

After identifying which hints a site requests, check the Request Headers of a subsequent navigation to confirm that your browser is honoring the Accept-CH directive. Chrome sends the requested hints automatically without any user notification. A `Sec-CH-UA-`Arch header in your outgoing requests confirms that the server received your CPU architecture, restoring a dimension of detail that UA Reduction was designed to remove from the passive User-Agent string.

Using the Permissions Policy header to restrict hint sharing

If you control a web property that embeds third-party scripts, you can use the Permissions-Policy response header to prevent those third-party iframes from requesting high-entropy hints without your consent. Adding "Permissions-Policy: ch-ua-arch=(), ch-ua-platform-version=()" to your response headers blocks the embedded scripts from receiving those values, even if they send their own Accept-CH headers. This is the recommended pattern for operators who want to send hints to their own analytics endpoint without exposing the same data to every embedded third-party script on the page.

How Client Hints compare to legacy User-Agent string fingerprinting

The User-Agent string and Client Hints represent two different philosophies for browser identification. The legacy UA string sent all available information unconditionally on every request, exposing the full OS version, CPU architecture, browser build version, and rendering engine in a single passive header. Client Hints replace this with a graduated disclosure model where low-entropy values are sent by default and high-entropy values require explicit server permission.

From a fingerprinting perspective, the two approaches produce similar results when servers use Accept-CH to request all available high-entropy hints. The difference is visibility: Accept-CH requests are logged in Network DevTools, making them auditable, whereas the legacy UA string exposed equivalent data silently. This auditability is the privacy improvement that Client Hints actually deliver, not a reduction in available fingerprinting data.

Firefox and Safari users are unaffected by UA Reduction because neither browser adopted the Client Hints API. Both continue to send a legacy User-Agent string, and Firefox's string still includes the full platform version. Auditing which Client Hints your browser actually sends shows whether a server's Accept-CH headers are capturing high-entropy data from Chrome users while falling back to legacy UA strings from Firefox and Safari visitors.

When to use this

Run the inspector above when auditing which Client Hints a server requests from your browser, or when implementing Accept-CH in a web application and weighing the privacy tradeoffs of which high-entropy hints to request from users.

Examples

Open DevTools > Network panel, reload the page, select the initial document request, and check the Response Headers tab for an `Accept-CH` header.

A site sending "`Accept-CH`: ``Sec-CH-UA`-`Arch, ``Sec-CH-UA`-`Platform-Version" is requesting your CPU architecture and OS version. Your browser will send these on subsequent requests to this origin.

```navigator.userAgent`Data`.brands` returns the low-entropy brand list immediately and synchronously.

```navigator.userAgent`Data`.getHighEntropyValues`(["architecture", "platformVersion"]) returns a Promise. Awaiting it yields { architecture: "x86", platformVersion: "15.0" }; values not available in the synchronous UA string after UA Reduction.