Why Deprecating an HTTP Header Takes Years

The user agent header has been described as deprecated for a long time and is still sent by every browser. The gap between intent and removal is structural rather than a lack of will.

Consumers are invisible to the vendor

A browser vendor can measure what browsers send. It cannot measure what servers do with what they receive, because that happens entirely outside its view.

Code reading the header lives in applications, appliances, log pipelines and libraries that report nothing back to anyone.

So the population that would break is unknown in both size and composition, which makes any removal an uncontrolled experiment.

Breakage is silent, not loud

Removing the header rarely produces an error. It produces a subtly wrong decision: the fallback path, the default asset, the unknown bucket.

Silent wrongness does not generate reports, so the vendor learns nothing from a staged rollout except that nobody complained.

That is exactly the kind of change that appears successful and accumulates damage, which vendors have learned to be cautious about.

Reduction is a safer path than removal

Freezing components at fixed values keeps every parser working while shrinking what the header discloses. Consumers continue to succeed and receive less.

Each freeze can be rolled out gradually and reversed if problems surface, which removal cannot be once sites adapt to the absence.

The approach trades a clean endpoint for a controllable process, which is the right trade when the consumer population is unknown.

Alternatives must be genuinely sufficient

A replacement is only viable when it covers the legitimate uses of what it replaces. Client hints took years to reach that point across the cases sites actually have.

Gaps remain, notably the first-request case and non-browser clients, and those gaps are themselves arguments against removal.

Deprecation that leaves real needs unmet produces worse outcomes, as consumers reach for less appropriate signals to fill the gap.

The endpoint may never arrive

Several long-deprecated web features remain implemented because removal was never demonstrably safe. This header has stronger claims to permanence than most.

The realistic expectation is a header that persists indefinitely in reduced form, alongside a structured channel carrying anything precise.

Detection code should be written for that steady state rather than for an eventual cutover, because planning around a removal that may not happen is its own risk.