How Brand Lists Break Naive Version Parsing

The brand hint does not return one browser name. It returns a list, and the list is constructed in a way that deliberately punishes code assuming a single entry.

A browser has several defensible brands

A product built on a shared engine can honestly claim its own name, the name of the underlying open project, and a compatibility identity that sites recognise. All three are meaningful.

Returning one of these forces a choice that will be wrong for some consumers. Returning all of them lets the consumer match whichever matters for its purpose.

This reflects how sites actually branch. Some target a product, some target an engine family, and a list serves both without either having to guess.

The list contains deliberate noise

Browsers include an entry that is not a real brand, and vary it. Its presence ensures that any code assuming a fixed position or a fixed count encounters something unexpected.

This is a design decision borrowed from other standards work: build variation into the interface so that consumers cannot depend on incidental stability.

Code written to the specification handles it without noticing, because it searches the list for the brand it cares about. Code written to observed output breaks quickly, which is the intent.

Order is not meaningful

Entries may appear in any order, and the order may change between requests. Nothing designates a primary brand.

A consumer wanting to know whether a particular family is present must search the list. Taking the first entry produces a correct-looking answer that is unrelated to the question.

This is the most common mistake in early hint adoption, largely because the legacy header trained everyone to read by position.

Versions attach per brand

Each entry carries its own version, so the version of a product and the version of the engine family it reports are separate values that may differ substantially.

Matching a brand and then reading its version keeps the pair together. Reading a version from one entry and a name from another produces a combination that never existed.

The default brand list carries only a major version. A full version list is available as a high-entropy hint for cases that genuinely need it.

Writing consumer code correctly

The correct pattern is a lookup: iterate the list, match the brand of interest, use the version attached to that entry, and handle the absence of a match as a normal outcome.

Absence really is normal. A browser outside the family being checked will not appear, and that should route to a capability-based path rather than a failure.

Written that way, the noise entry and the variable ordering never matter. The design is testing whether the consumer asked a question or made an assumption.