What a Build Identifier Actually Encodes

Alongside version numbers, many user agent strings carry a build identifier. Knowing what it originally encoded explains both its usefulness and why it has largely been neutralised.

Builds identified a compilation, not a release

A release version names what users downloaded. A build identifier names the specific compilation, which could differ by platform, channel or a late fix within the same nominal version.

For a vendor triaging crash reports this distinction matters enormously. Two users on the same version may be running different code.

For a website it almost never matters. Very little site behaviour depends on differences that do not change the version number.

The format was vendor-specific

Some vendors used a date-like sequence, others a monotonic counter, others an internal revision reference. None of these were documented as stable interfaces.

Because the formats differed, no general parser could interpret them. A build token was a string a vendor understood and everyone else copied verbatim.

Attempts to derive meaning from them, such as inferring a release date, worked for one vendor and produced nonsense for the next.

Fine-grained builds made clients distinguishable

The narrower a value, the smaller the group of users sharing it. A build token specific to one platform and channel splits the population much more finely than a major version does.

That granularity was the reason to reduce it. A field that distinguishes small groups of users contributes disproportionately to how identifiable a request is.

Vendors responded by emitting constant values in the build position rather than removing the position, which would have broken parsers that expect it.

Constant builds break assumptions quietly

Code that compares build tokens now compares two identical constants and concludes the clients are the same build. The comparison succeeds and means nothing.

This is a worse failure than a missing field. Absence is detectable; a plausible constant is not, and downstream logic proceeds with confidence it has not earned.

Anyone maintaining analysis over historical logs will see build diversity collapse at a point in time. That is a reporting change, not a change in the population.

Where build detail still lives

Vendors retain build information through their own crash and telemetry channels, which is where it was always most useful. It does not need to travel on every HTTP request.

Structured hints expose a full version list to sites that request it and are permitted, keeping the detail available where there is a stated reason for it.

The general pattern is worth noting: detail moved from a broadcast header to a channel where it is requested explicitly. That trade is the direction most of this ecosystem is moving.