Methodology

Every statement on this site is meant to be traceable: to a specification, a vendor document, a browser-compat-data file or a measured number. This page defines the vocabulary the compatibility tables use, names the upstream sources, states how often entries are checked, publishes the formula behind the by-country view, and draws the boundary of what OpenPWA covers.

Support statuses

Each row of a compatibility dataset describes one browser on one operating system and carries exactly one status:

• yes. The feature works as specified in the cited version and later. The row records the first version that shipped it (version_added).
• partial. The feature is available but a documented part of it is missing, differs from the specification or works only on some surfaces. The row records what is missing in its notes and, when a later version completed the implementation, that version too.
• flag. The feature exists only behind a runtime flag, an origin trial or a developer setting. It is not available to ordinary users, so it counts as half support in the country-reach weighting below.
• no. The browser does not implement the feature in any shipping version, or removed it.
• unknown. No source could be found that settles the question. A row is never marked unknown to avoid saying no; it is marked unknown when the editors could not find out.

A row whose status is anything other than yes carries a note explaining why.

Confidence

Confidence describes the class of evidence behind a row, not the editor’s feeling about it:

• high. The row cites a raw browser-compat-data file and the automated cross-check (check-bcd) finds the row in agreement with that file: same status class, same first version.
• medium. The row cites a vendor document, release note, bug tracker entry or a specification, and no browser-compat-data entry exists for the feature or the cited data disagrees with it in a way the notes explain.
• low. The row is inferred: from engine family (a Chromium-based browser inheriting a Chromium feature), from a vendor statement of intent, or from a test the editors ran without a published document to point at.

A dataset’s confidence is the lowest confidence of its rows for the browsers that matter for the feature. When the cross-check finds a disagreement, the row is corrected and the correction is listed in the site changelog.

Upstream data sources

• browser-compat-data (MDN). Each high row cites the exact raw JSON file in the mdn/browser-compat-data repository that it was derived from, and the deploy pipeline re-reads that file and compares every cited row before a build is published.
• MDN Web Docs reference pages, for API shape and behaviour descriptions.
• Vendor documentation and release notes: Apple’s Safari and WebKit release notes, the Chrome and Chromium release notes and developer.chrome.com, Mozilla’s Firefox release notes and developer.mozilla.org, Microsoft Edge documentation and the Samsung Internet release notes. These back medium rows and every platform-behaviour statement.
• Specifications: W3C, WHATWG and WICG documents, cited as spec_url on every dataset and as sources on reference entries.
• StatCounter GlobalStats for browser market share, used only by the by-country view. The current snapshot is the 2026-05 month for nine regions: global, Brazil, China, Germany, India, Indonesia, Japan, Nigeria and the United States. Shares are rounded to whole percent and grouped into the browser families the datasets use (Chrome, Safari, Edge, Firefox, Samsung Internet, Opera, other).
• web-platform-tests are not an upstream at present. No status on this site is derived from a wpt.fyi result; when that changes, the rows that depend on it will say so in their notes.

Verification cadence

• Every entry carries a lastVerified date in its frontmatter, shown as “Last verified” at the end of the page. The date moves only when an editor re-checked the entry against its sources.
• Entries are scanned for age on every pipeline run. A reference, guide or compatibility entry older than 180 days is queued for re-verification; a page whose facts depend on a store or platform policy is queued after 90 days, measured from its separate policyCheckedAt date, because policy text changes without a release note.
• Before any entry is published or re-published, the pipeline requires, in order: every cited source reachable; every compatibility row in agreement with the browser-compat-data file it cites; the entry’s structure complete for its kind; the English and Chinese versions both present; an independent fact-check, in which a model different from the one that drafted the text reads each claim against the cited sources and must find no contradiction; and sign-off by the editor. A failure at any step withholds the publish. There is no override.
• The pipeline runs on a daily schedule. A day with no eligible work publishes nothing.
• Substantive changes to published facts are recorded in the site changelog with the date, the page and a one-line summary; corrections are labelled as corrections.

Country reach

The by-country view answers “what share of users in region R can use feature F”, weighted by which browsers people there actually use. It is computed at build time from the compatibility datasets and the StatCounter shares; nothing in it is typed by hand.

For a feature F and a region R with browser families b and shares s(b):

reach(F, R) = 100 × Σ_b s(b) × contribution(F, b) / Σ_b s(b)

where contribution(F, b) is the mean status weight of F’s support rows for family b, with weights yes = 1, partial = 0.5, flag = 0.5, no = 0, unknown = 0. A family with no row for F contributes 0, which errs on the side of under-reporting. Dividing by the sum of the shares normalises regions whose share table does not add up to exactly 100.

Example: Japan (2026-05) is Safari 49, Chrome 38, Edge 6, Firefox 3, Samsung 1, Opera 1, other 2. A feature that is yes in Chrome, Edge and Samsung Internet, partial in Safari and no in Firefox scores 100 × (38 + 6 + 1 + 0.5 × 49) / 100 = 69.5 %. The view rounds to whole percent.

Limits: the shares are a monthly snapshot, not live; the weights are a convention (a partial implementation may be useless or nearly complete); desktop and mobile rows for the same family are averaged, not split by device share. The number is a planning aid, not a measurement.

Scope

• The web app manifest and its members; service workers and their lifecycle; installation across platforms; device and platform capabilities reachable from a PWA; storage; push and notifications; performance primitives that matter for installed apps; platform behaviour on iOS and macOS Safari, Chrome and Android, Edge and Windows, Firefox, Samsung Internet and ChromeOS.
• Browser-support datasets for those features, with the policy dimension (ad networks, payment SDKs, app stores) recorded as separate rows with their own sources.
• Guides that connect the reference entries into a task, and dated News articles on platform changes, each tracing back to a primary source.
• Both locales as first-class: every entry ships in English and Chinese or not at all.

Non-goals

• No app store, catalogue, ranking or “install this app” surface.
• No framework or library comparisons, and no benchmarks of build tools.
• No in-house device laboratory. Statuses come from the upstream sources above; where the editors observed a behaviour on a device, the entry says so and gives the browser and OS version, and the row’s confidence stays low until a published source exists.
• No screenshots of vendor UI at present; flow pages use diagrams instead. When device captures are added, the entries that gain them will be listed in the changelog.
• No tutorials that restate MDN. Where MDN already documents an API fully, the entry links to it and spends its words on what MDN does not say: installed-app behaviour, platform differences, policy and measured limits.