How do I explain which devices or browsers a product supports?

First define what “support” means in this statement. Name the product area, feature, or task, then list only the browsers or devices your records cover. Include version or operating-system details only when the records establish them. Add a check date when one is recorded, and include a contact route only if your organization provides one.

Avoid a broad sentence such as “Our product works on every browser.” It could imply that every feature works on every device and version, even when the evidence is narrower. MDN’s compatibility-table guidance concerns shared web technologies, not any particular commercial product. Its useful principle is to tie compatibility information to the relevant feature and browser rather than generalize about an entire product. [S1]

When support differs, organize the information by feature or task and browser or device. That helps readers find the combination they care about without assuming that one feature’s support applies to everything. MDN describes browser compatibility tables for web-platform features as using data keyed to the specific feature; this is a useful model for scoped presentation, not evidence about your own product. [S1]

Here is a worksheet example, not a claim about a real product. In a document or content system, keep each entry together as a row or clearly separated item:

• Feature or task: [Feature A]
• Browser/device and version: [Exact combination checked]
• Result: [Verified result, known limitation, or not checked]
• Source-verification field: [Record title or identifier; what it covers; date checked]

Repeat those fields for each feature and combination. Do not leave a blank result that readers might mistake for approval. Use labels such as “verified” or “known limitation” only when the records support them; if there is no relevant record, say “not verified.”

No. Baseline summarizes support for web-platform features across its defined set of desktop and mobile browsers. It distinguishes widely available, newly available, and limited-availability features. Newly available features may not work in older browsers or devices. Baseline also does not establish accessibility, usability, performance, security, or complete compatibility outside its browser set. [S2]

If you mention Baseline, name the particular web feature and the status established by your source. Keep that distinct from evidence about your product’s behavior. For example: “The [feature] has [verified status] according to [record]. Product support for [task] was checked separately on [browser/device and version] on [date].” Fill in those fields only from records you can inspect. If the product task has not been verified, say so rather than using a platform summary as a substitute.

Use this block as a starting point. Replace placeholders only with confirmed information, and keep the source-verification field in your working worksheet:

Compatibility for [product area or task]

• Verified browsers/devices: [Exact names and versions checked]
• What was checked: [Features or tasks covered]
• Known limitations: [Confirmed limitations, or “Not established by the records reviewed”]
• Not verified: [Browsers, devices, versions, or tasks not checked]
• Last checked: [Date, if recorded]
• Source-verification field: [Record title or identifier; scope; date checked; responsible person or team, if recorded]

Before publishing, compare every public claim with the record named in the verification field. Evidence for one browser, version, or feature does not establish support for other combinations. If a record is missing or unclear, leave the claim out or label it unverified. Compatibility for a particular product must come from product-specific records.