Why Client Hints Split Into Low and High Entropy

Client hints separate browser information into two tiers with different default behaviour. The line between them is drawn by how sharply each value distinguishes one client from another.

The low-entropy set is sent unprompted

A small group of hints accompanies requests without any server request. It covers coarse facts such as the browser brand list, whether the client is mobile, and the platform name.

These values are shared by very large populations. Knowing that a client is a mobile browser on a common platform narrows almost nothing, which is why sending them by default is acceptable.

The set is deliberately small and deliberately coarse. Its purpose is to cover the majority of legitimate detection needs without any negotiation step.

The high-entropy set requires an explicit request

Exact versions, platform version, architecture, bitness and device model are withheld until a server asks. Each narrows the population far more than the coarse equivalents.

Asking is a public, inspectable act. A response header names the hints the origin wants, which makes the request visible in a way that passive header parsing never was.

The browser may decline. Nothing in the design obliges it to answer, and policy or user settings can suppress a hint the site has requested.

Entropy is the organising principle

The tiering is not about sensitivity in an ordinary sense. It is about how many users share a value, which determines how much a field contributes to distinguishing one request from another.

Device model illustrates this well. On a widely sold device the value is shared broadly; on an uncommon one it narrows the population to a small group immediately.

Because the contribution varies by value rather than by field, the design places the whole field in the higher tier. Field-level rules are the only ones that can be applied consistently.

Detection needs mostly sit in the low tier

Most real branching wants to know whether to serve a mobile layout, which brand family is rendering, or roughly which platform is in use. All of that is in the default set.

Sites requesting high-entropy hints are usually chasing a specific defect, an installer download or a hardware-dependent asset. Those are real cases and a minority of them.

The split therefore encodes an assumption worth stating: broad detection is common and cheap, precise identification is rare and should cost a request.

What this changes for implementers

Code should be written against the low-entropy set first and only request more when a concrete requirement fails without it. That ordering keeps the default path free of negotiation.

Requesting everything preemptively works but is poor practice. It makes the site's data appetite visible without a corresponding need and invites the browser to apply policy against it.

The design rewards asking for exactly what a feature requires, which is a healthier relationship with client data than parsing whatever happens to arrive.