Client Hints

Client Hints is an opt-in framework enabling servers to request specific information from clients about device capabilities, network conditions, and user preferences. Servers use this information to select the best representation of a resource through proactive content negotiation.

The framework is extended by the WICG Client Hints Infrastructure specification. User-Agent Client Hints have shipped stable in Chromium-based browsers as part of the broader effort to reduce the information exposed by the User-Agent string.

Table of Contents

Baseline: Limited availability

Not supported in all major browsers. webstatus.dev

How Client Hints work

The Client Hints flow has three parts: the server advertises which hints the server wants, the client sends them on subsequent requests, and the server includes the hint names in Vary so caches store the correct variants.

Accept-CH

The server sends the Accept-CH response header listing the hints the server accepts. The client persists this preference and includes the requested hints on subsequent same-origin requests over HTTPS.

Accept-CH: Sec-CH-UA-Full-Version-List, Sec-CH-UA-Model, ECT, Device-Memory

The opt-in is origin-scoped. Hints are only sent to the requesting origin. Delivery to third-party origins requires explicit delegation through Permissions-Policy.

Critical-CH

Critical-CH lists hints the server considers essential enough to warrant a request retry when missing. If a client receives a response containing Critical-CH and recognizes the browser now has hint data not included on the original request, the browser retries the navigation automatically. The retry happens at most once per request.

Accept-CH: Sec-CH-Prefers-Color-Scheme, ECT
Critical-CH: Sec-CH-Prefers-Color-Scheme

In this exchange, the server signals the preferred color scheme matters enough to justify a round-trip penalty on first load. The ECT hint is requested but not critical and arrives starting with the next navigation.

First-load cost

Critical-CH triggers an extra round trip on the first visit before the client has cached the server's hint preferences. For HTTP/2 and HTTP/3 connections, the ACCEPT_CH frame delivered during the TLS handshake eliminates this cost by communicating hint preferences at the connection level.

Permissions-Policy delegation

By default, client hints are sent only to the requesting origin. To forward hints to a third-party origin embedded in the page, the server sets a Permissions-Policy header granting the feature to the embedded origin.

Permissions-Policy: ch-ect=(self "https://cdn.example.re"), ch-device-memory=(self "https://cdn.example.re")

The third-party origin must also request the hints through its own Accept-CH header. Both the first-party delegation and the third-party opt-in are required for the client to send hints cross-origin.

Vary

When the server adapts a response based on a client hint, the hint name belongs in the Vary header. Caches key stored responses on these fields, ensuring each client receives the variant selected for its specific hint values.

Vary: ECT, Save-Data, Sec-CH-UA-Mobile

Privacy model

Client Hints replace passive fingerprinting surfaces with an active opt-in model. Rather than sending extensive device and browser data on every request through the User-Agent string, the framework requires the server to explicitly ask for each piece of information. The client decides which hints to honor.

Low-entropy and high-entropy hints

Hints are divided into two categories based on the amount of identifying information they expose.

Low-entropy hints carry minimal fingerprinting risk and are sent by default, even without an Accept-CH opt-in:

High-entropy hints expose more detailed information and require explicit server opt-in through Accept-CH:

Values for network hints like RTT and Downlink are rounded (RTT to the nearest 25 ms, Downlink to the nearest 25 Kbps) to reduce fingerprinting precision. The ECT header reports a coarse connection category rather than exact speed figures.

GREASE

User-Agent Client Hints include a GREASE (Generate Random Extensions And Sustain Extensibility) mechanism. Browsers append an extra brand entry with a randomized name and version to the Sec-CH-UA and Sec-CH-UA-Full-Version-List values. The brand ordering is also randomized. This prevents servers from relying on exact brand-list matching and encourages parsers to handle unknown entries gracefully.

Sec-CH-UA: "Chromium";v="128", "Not;A=Brand";v="24", "Google Chrome";v="128"

The "Not;A=Brand" entry is the GREASE value. Its name and version change across browser releases.

User-Agent Client Hints

The Sec-CH-UA family of headers provides a structured replacement for the User-Agent string. Chromium-based browsers completed the User-Agent string reduction effort, freezing portions of the UA string and directing servers toward these headers for detailed information.

Header Entropy Description
Sec-CH-UA Low Brand list with major versions
Sec-CH-UA-Mobile Low Mobile device indicator (?0 or ?1)
Sec-CH-UA-Platform Low OS name ("Windows", "Android", "macOS")
Sec-CH-UA-Full-Version-List High Brand list with full versions
Sec-CH-UA-Platform-Version High OS version
Sec-CH-UA-Arch High CPU architecture ("x86", "arm")
Sec-CH-UA-Bitness High Architecture bitness ("32", "64")
Sec-CH-UA-Model High Device model (empty on desktop)

Browser support

User-Agent Client Hints are supported by Chromium-based browsers (Chrome, Edge, Opera). Firefox and Safari have not implemented them.

Deprecated

Sec-CH-UA-Full-Version is deprecated. Use Sec-CH-UA-Full-Version-List instead. The single-version header provided only the primary browser's version, while the list variant includes versions for every brand in the brand set.

Network hints

Network hints report connection characteristics, allowing the server to adapt resource weight and quality to current conditions. These headers do not carry the Sec-CH- prefix.

Header Description
Save-Data User preference for reduced data (on)
RTT Round-trip time in ms (rounded to 25 ms)
Downlink Bandwidth in Mbps (rounded to 25 Kbps)
ECT Effective connection type (slow-2g, 2g, 3g, 4g)

Save-Data is a low-entropy hint sent by default when the user has enabled a data-saving mode. The remaining network hints are high-entropy and require Accept-CH opt-in.

Accept-CH: ECT, RTT, Downlink, Save-Data

A server receiving ECT: 2g with Save-Data: on has a clear signal to serve lightweight assets: compressed images, deferred scripts, and reduced payload sizes.

Adaptive serving

Network hints pair well with content negotiation. A server responding differently based on ECT or Save-Data includes those header names in Vary so CDN caches store and serve separate variants per connection quality.

User preference hints

User preference hints reflect operating system and browser accessibility settings, enabling servers to tailor responses at the HTTP level rather than relying solely on CSS media queries.

Header Values
Sec-Ch-Prefers-Color-Scheme sec-CH-Prefers-Color-Scheme
Sec-Ch-Prefers-Reduced-Motion sec-CH-Prefers-Reduced-Motion
Sec-CH-Prefers-Reduced-Transparency "no-preference", "reduce"
Sec-CH-Prefers-Contrast "no-preference", "less", "more", "custom"
Sec-CH-Forced-Colors "none", "active"

These are all high-entropy hints. The server requests them through Accept-CH and marks essential ones with Critical-CH.

Accept-CH: Sec-CH-Prefers-Color-Scheme
Critical-CH: Sec-CH-Prefers-Color-Scheme

Sec-CH-Prefers-Color-Scheme is supported in Chromium-based browsers. The remaining headers have limited or no browser support.

Server-side dark mode

Knowing the preferred color scheme at request time lets the server inline the correct stylesheet or render the appropriate theme in the initial HTML response, avoiding the flash of incorrect colors on first load.

Device hints

Device-Memory reports the approximate RAM available on the device as a value from a fixed set: 0.25, 0.5, 1, 2, 4, or 8 (in gigabytes). This is a high-entropy hint.

Accept-CH: Device-Memory

Device-Memory: 4

A server receiving a low Device-Memory value serves lighter JavaScript bundles or reduces the complexity of rendered content.

Deprecated device hints

The original device hint headers DPR, Width, Viewport-Width, and their response counterpart Content-DPR have been deprecated. Proposed replacements (Sec-CH-DPR, Sec-CH-Width, Sec-CH-Viewport-Width, Sec-CH-Viewport-Height) were specified but never shipped in any browser. Responsive images through the HTML <picture> element and srcset attribute handle these use cases on the client side without requiring server involvement.

Example

A server opts into User-Agent Client Hints and network hints. The client responds with the requested information on the next request.

Initial response

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Full-Version-List, Sec-CH-UA-Model, ECT, Save-Data
Vary: Sec-CH-UA-Mobile, ECT, Save-Data
Critical-CH: Save-Data

Subsequent request

GET /app HTTP/1.1
Host: www.example.re
Sec-CH-UA: "Chromium";v="128", "Not;A=Brand";v="24", "Google Chrome";v="128"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Full-Version-List: "Chromium";v="128.0.6613.84", "Not;A=Brand";v="24.0.0.0", "Google Chrome";v="128.0.6613.84"
Sec-CH-UA-Model: "Pixel 8"
ECT: 4g
Save-Data: on

The three low-entropy UA hints (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform) are always present. The high-entropy hints (Sec-CH-UA-Full-Version-List, Sec-CH-UA-Model) and network hints (ECT, Save-Data) appear because the server requested them through Accept-CH.

Takeaway

Client Hints provide an opt-in framework for proactive content negotiation, replacing passive data collection with privacy-respecting server requests. The Accept-CH and Critical-CH headers control which hints the server receives. Permissions-Policy governs delegation to third parties. User-Agent Client Hints have shipped stable in Chromium-based browsers as the structured successor to the User-Agent string, while network and preference hints enable adaptive serving based on real connection conditions and accessibility needs.

See also

Last updated: March 11, 2026