# Baseline support overview

> What Baseline means, its three tiers, the seven tracked browsers, the 30-month window, and Baseline 2026 as the yearly feature set that stays open through 2026.

Baseline is a cross-browser support signal for web platform features (APIs, CSS
properties, and JavaScript syntax) expressed as one of three tiers, widely available,
newly available, or limited availability, based on consistent support in seven browser
and platform combinations. "Baseline 2026" is the yearly feature set collecting the
features that reach newly available during 2026, and it stays open until the year ends.

## How it works

Baseline was started by the Chrome team and is defined by the
[W3C WebDX Community Group](https://www.w3.org/community/webdx/); the data is published
as the `web-features` npm package from the
[web-platform-dx/web-features](https://github.com/web-platform-dx/web-features)
repository, which is what MDN, Can I Use, Lighthouse, and DevTools read.

### The seven browsers whose support counts

[MDN's Baseline glossary entry](https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility)
lists the fixed set a feature is judged against: Safari on iOS, Safari on macOS, Chrome on
Android, Chrome on desktop, Edge on desktop, Firefox on Android, and Firefox on desktop.
Browsers outside the set do not move a feature between tiers: Samsung Internet, Opera,
the Android WebView, and the WeChat WebView are not counted, so a feature can be
"widely available" and still fail in an embedded WebView.

### The three tiers

| Tier | What qualifies | MDN badge |
|---|---|---|
| Widely available | Consistent support in each of the seven browsers for at least 30 months | Green check |
| Newly available | Works in at least the latest stable release of each of the seven browsers | Blue check with the year, for example "Baseline 2022" |
| Limited availability | Missing from at least one of the seven | Grey cross |

The 30-month clock on [web.dev/baseline](https://web.dev/baseline) starts on the
feature's keystone date, which the
[Baseline definition](https://github.com/web-platform-dx/web-features/blob/main/docs/baseline.md)
defines as the release date of the last core browser to add support (reading
`@mdn/browser-compat-data` and excluding `partial_implementation` entries), not on the
yearly label. The high tier has a second condition: the keystone date must also precede
the latest Firefox x.0 ESR release, so a feature Firefox shipped shortly after an ESR cut
can wait past the 30 months. Ignoring that clause, a feature that reached newly available
in 2026-02 becomes widely available in 2028-08; one that crossed in 2026-11 waits until
2029-05, so two features in the same "Baseline 2026" set can graduate 9 months apart.

### Yearly feature sets

Features are also grouped by the calendar year in which they crossed into newly
available: web.dev defines Baseline 2024 as "all items that become part of Baseline Newly
available in 2024", applies the same formula to 2025, and describes 2026 as the latest
feature set, still in development. Baseline 2026 is therefore not a closed list; it
grows through 2026-12 as browser releases land. The Baseline status for the PWA features
tracked on this site is read per browser in [By browser](/compatibility/by-browser/),
which also shows the browsers Baseline leaves out.

## Examples

Baseline is a build-time signal with a published data shape; it says nothing at runtime,
so the two examples sit on opposite sides of the deploy.

### Reading a feature's Baseline status from web-features

The `web-features` package exposes each feature's `status` with `baseline` set to
`"high"`, `"low"`, or `false`, the dates `baseline_low_date` and `baseline_high_date`, and
a `support` map keyed `chrome`, `chrome_android`, `edge`, `firefox`, `firefox_android`,
`safari`, and `safari_ios` holding the version that most recently introduced the feature
([data.schema.json](https://github.com/web-platform-dx/web-features/blob/main/schemas/data.schema.json),
github.com). A build script can gate a code path on it:

```js
import { features } from 'web-features';

const { status } = features['web-share'];
if (status.baseline === 'high') {
  console.log(`Widely available since ${status.baseline_high_date}`);
} else if (status.baseline === 'low') {
  console.log(`Newly available since ${status.baseline_low_date}; Firefox ${status.support.firefox ?? 'none'}`);
} else {
  console.log('Limited availability: ship the fallback path');
}
```

The `support` map is where the per-browser detail lives; `baseline` alone does not say
which of the seven browsers is missing.

### Detecting the feature itself at runtime

A "widely available" badge does not reach the browser the user is holding, and WebViews
are outside the definition, so the page still tests for the API and keeps a fallback:

```js
async function shareOrCopy(url) {
  if (!('share' in navigator)) {
    await navigator.clipboard.writeText(url); // no share sheet: copy instead
    return 'copied';
  }
  await navigator.share({ url });
  return 'shared';
}
```

Baseline decides whether the fallback is worth maintaining; feature detection decides
whether it runs.

## Observed behaviour

Baseline measures browser support only. MDN states that it "is not a substitute for
accessibility, usability, performance, security, or other testing", and that it may not
reflect older devices and releases, browsers outside the definition such as operating
system web views, or assistive technology. For a PWA that means the manifest, install
prompt and WebAPK behaviours documented on the other platform pages are judged per browser
and per OS, not by a tier.

:::observed
The MDN reference page for the manifest `display` member carries the banner
"Limited availability — This feature is not Baseline because it does not work in some of
the most widely-used browsers." (English UI, read 2026-10). This site's `manifest-display`
dataset records the member as supported in Chrome 39 on Android, Chrome 73, Edge 79, Safari
11.3 on iOS, Safari 17 on macOS, and Samsung Internet 4.0, and as unsupported in desktop
Firefox, which has no manifest-driven install path; one missing browser of the seven is
enough to keep a feature in the limited tier.
:::

Baseline status is surfaced in the tools listed on web.dev/baseline: the Chrome DevTools
Elements panel for CSS properties, a Lighthouse "Baseline Features" audit, ESLint CSS
rules, Browserslist queries, the webstatus.dev dashboard, VS Code, and a Netlify
extension. Each of them reads the same `web-features` data, so a disagreement between two
tools is a version skew of the package, not a different judgement.

## See also

- [Baseline (compatibility)](https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility) (developer.mozilla.org)
- [Baseline](https://web.dev/baseline) (web.dev)
- [web-platform-dx/web-features](https://github.com/web-platform-dx/web-features) (github.com)
- [By browser](/compatibility/by-browser/)
- [By OS](/compatibility/by-os/)
- [PWAs on Firefox](/reference/platforms/firefox/)