A reference page can contain hundreds of User-Agent strings and still leave the reader unable to trust any one row. The missing information is usually not another token. It is provenance: where the sample came from, when it was observed, which platform it represents, and what the string cannot prove. A browser label should be a useful lead for debugging, not an authoritative claim about a person or a device.
The anatomy of a useful row
Our minimum entry has a raw sample or a redacted sample, normalized family, major version, platform scope, observation date, source class, confidence, and a note about limitations. The source class might be a controlled lab fixture, an anonymized support report, a public documentation example, or a traffic estimate. Those sources answer different questions and should not be presented as interchangeable.
Here is an illustrative record for a reduced Chromium sample:
{
"family": "Chromium",
"major": 124,
"platform_scope": "desktop example",
"observed": "2026-05-30",
"source": "lab fixture",
"confidence": "high for family, low for device model",
"cannot_prove": ["browser owner", "person identity", "exact device"]
}The last field is as important as the first. A reader may copy a label into a support rule. They need to know whether it is safe to use for routing, reporting, or only for a reproduction hint.
Examples need a source trail
When a value comes from a support ticket, remove session IDs, cookies, private URL parameters, customer names, and account tokens before it enters the editorial queue. Keep the original ticket reference in a restricted workflow if the operator needs to verify it, but do not publish that reference as proof. When a value comes from a fixture, keep the browser, operating system, driver, and date beside the sample so another engineer can recreate it.
The same rule applies to estimates. A number labelled “browser share” without a population, time window, geography, and bot-filtering rule is not a fact waiting to be formatted. It is an unnamed measurement. Put the scope in the title or first sentence rather than hiding it in a footnote.
Make corrections visible
When a row changes, keep the old value in the internal review record and write a short public change note. State whether the correction came from a parser bug, a new fixture, a support report, or a scope change. Readers do not need private ticket details, but they do need to know why the label moved from confirmed to limited or why a platform claim was removed.
An illustrative review record might say that a sample previously labelled iPhone Safari was changed to mobile WebKit because the available evidence showed only a WebKit token and a mobile marker. The correction is less specific, but it is more defensible. A less exciting label can prevent a team from routing a bug to the wrong platform owner.
The same restraint applies to screenshots. A screenshot can show a layout or visible failure, but it cannot prove the underlying browser family. Keep the screenshot beside the reproduction steps and label the identity evidence separately. This lets another engineer repeat the journey without inheriting an unsupported conclusion.
Give each consumer a safe field
Reference readers may need a family and major version. Support may need the reproduction context. Analytics may need only a coarse bucket. Store those outputs separately rather than making one label carry every interpretation. If a new consumer needs more detail, document the new decision and its retention before extending the row.
Separate observation from interpretation
An entry may show a Safari token and a Mobile token. That supports an observation about the reported string. It does not prove that the link opened in Safari, that the device is an iPhone, or that the host app was absent. A WebView marker may be strong evidence of an embedded context, but even then the product journey needs reproduction.
Use language that exposes the boundary: “the sample contains,” “the parser classified,” “the fixture was observed on,” and “this value does not establish.” Avoid “the visitor is” when the evidence is only a header. Precision makes the page more useful, not less confident.
Editorial review can be repeatable
Before publishing a row, a reviewer should be able to answer five questions:
- Can the sample be reproduced or traced to an approved source?
- Is the date and platform scope visible?
- Are inferred fields labelled as inferred?
- Were secrets and personal data removed?
- Does the example point to the decision it can support?
If the answer to one is no, keep the entry in draft or publish it as an explicitly limited example. Archive stale records with their old date instead of silently rewriting them. Incident reviews often need to understand what a header looked like before a browser change.
The page should earn its authority
A long table becomes trustworthy through small acts of restraint: a source note, a confidence label, an old example kept intact, and a sentence explaining what not to infer. Community posts can add colour and edge cases, but the editorial page should not copy a post without checking its provenance and stripping private details.
Our standard is not that every row looks certain. It is that a reader can reproduce the observation, understand its scope, and decide whether the label belongs in their own compatibility matrix. That is the difference between a reference library and a pile of strings.