Why Client Hints Did Not Replace the Header Outright

Client hints were designed as a successor to the user agent header, yet the header is still sent. The decision to reduce rather than remove follows from how much code reads it.

Removal would break unmaintained code

Countless deployed systems read the header, including analytics pipelines, content management templates, security appliances and libraries embedded in software nobody has opened in years.

Much of that code treats an empty value as an error rather than as a missing optional field. Removal would produce failures rather than degraded behaviour.

Browsers cannot enumerate those systems, let alone coordinate with them. The safe move is to keep sending something that parses.

Reduction keeps the shape and drops the detail

The reduced header retains the familiar token structure while holding several components at fixed values. Parsers continue to succeed and extract less.

That is a much gentler failure mode. Code that branched on a detail now takes the default branch instead of encountering an unparseable value.

The information a site genuinely needs remains available through hints, so the capability is preserved while the default disclosure shrinks.

Non-browser clients are a large population

Scripts, command line tools, libraries, monitors and crawlers all send the header and none of them implement hints. For that traffic the header is the only identification available.

Server operators depend on it for routing, rate policy and log analysis. Removing it from browsers would not affect these clients but would fragment the field's meaning further.

A header that some clients send and others do not is harder to reason about than one everyone sends with varying precision.

The transition has no clear end

Deprecating a widely read header requires evidence that removal is safe, and that evidence is difficult to gather when the affected consumers are invisible.

Vendors have therefore reduced detail incrementally, watching for breakage at each step. Each reduction is small enough to reverse if it causes problems.

The practical result is that both mechanisms will coexist for a long time, and detection code should be written for that state rather than for its eventual resolution.

Writing for the dual-track period

Read structured hints where they are present and fall back to a deliberately coarse reading of the header where they are not. Do not maintain two detailed detection systems.

Keeping the fallback coarse limits the maintenance burden and avoids depending on components of the header that are already frozen or may be reduced next.

Anything requiring precision should be a capability test in the runtime, which is unaffected by whichever identification channel a client happens to use.