How to cite browser compatibility data without overpromising support

Browser compatibility citations should name the feature, the compatibility source, the checked date, and the support boundary that still needs testing.

Compatibility data is easy to overstate. A page may show that a feature is widely available, newly available, or limited, but that does not automatically mean every user context is safe. Enterprise browsers, embedded webviews, older mobile devices, and region-specific app shells can lag behind the broad support signal. The citation should help a developer decide what to verify, not provide a blanket guarantee.

Use MDN or Web Platform Baseline as the first structured signal when it fits the feature. Record the feature name exactly, because similar APIs or CSS properties can have different support histories. If the page has browser compatibility tables, cite the table and the checked date. If the page uses Baseline status, state whether the claim is about “widely available,” “newly available,” or not yet Baseline.

Then add the local boundary. For example: “Still test on the project’s supported Safari version and Android WebView target.” That sentence prevents a documentation note from becoming a release promise.

Avoid citing only a tutorial or Stack Overflow answer for support status. Tutorials may be correct when written but stale later. They can explain usage, but compatibility should come from a maintained compatibility source or from the project’s own test matrix.

The final note should be short enough to maintain: source, checked date, status, exception, next test. If any of those fields are missing, the citation will be harder to trust during a future migration.

How to cite browser compatibility data without overpromising support

// COMMENTS

ON THIS PAGE