How to tell whether a CSS feature is safe to ship

The short answer: a feature marked Baseline Widely available is safe to use without a fallback for most projects. Newly available means every major engine supports it, but not that your visitors have updated. Anything else needs a fallback or a @supports guard.

That's the summary most articles stop at, and it's close enough to be dangerous, because two of those phrases mean something more specific than they look. This is what the definition actually says, where it stops being useful, and how to turn it into a check your build runs for you.

What Baseline actually measures

Baseline is maintained by the W3C WebDX Community Group, and its status definition is a public document rather than a marketing term. It defines two statuses.

Interoperable, shown as "Newly available". A feature gets this when every current stable release in the core browser set supports it — as reported by @mdn/browser-compat-data, and excluding anything flagged as a partial implementation — and the specification doesn't carry discouraging language such as a deprecation notice.

The feature then gets a keystone date: the release date of the last browser to introduce support. If support was withdrawn and reintroduced, only the latest date counts.

Wider support, shown as "Widely available". The document is precise here, and this is the part people paraphrase wrongly. The rule is that the feature's "keystone date is on or before today's date minus 30 months", and also on or before the release dates of the current Firefox ESR long-term support releases.

The distinction matters: the 30 months are counted from the keystone date, not from the day the Baseline badge flipped to "newly available". Those are usually the same day, but not always — a feature whose status was held back by an editorial override, or whose data was corrected after the fact, can reach "widely available" sooner than a naive count suggests.

The core browser set is seven browsers

Both statuses are measured against exactly these:

• Chrome (desktop) and Chrome (Android)
• Edge (desktop)
• Firefox (desktop) and Firefox (Android)
• Safari (macOS) and Safari (iOS)

Nothing else. Not Samsung Internet, not Opera, not Edge on mobile, not the in-app webviews inside social and messaging apps. If your analytics show meaningful traffic from any of those — and the mix varies a lot between markets — Baseline on its own won't answer your question. The browserslist-config-baseline README makes the same point: "You should check your analytics to see which browser versions are prevalent in your userbase before selecting a Baseline target."

What Baseline will never tell you

The definition document lists its non-goals explicitly, which is unusually honest for a status badge and worth reading before you lean on it. Among them:

The progressive-enhancement one is the most useful omission to understand. Baseline says nothing about what happens when support is missing. Two features with identical Baseline status can behave completely differently: an unsupported corner-shape leaves you with an ordinary rounded corner, while an unsupported field-sizing leaves a form control at the wrong size. The first is safe to ship years before the second.

The four questions worth asking

Baseline is question one, not the whole interview.

1. What is its Baseline status? Widely available means ship it. Newly available means check the next three questions.
2. What does the page look like without it? If the answer is "slightly less polished", ship it now. If the answer is "broken", write a fallback regardless of status.
3. Who visits this site? Check real analytics for browser versions, not global averages. A tool used on managed corporate desktops and a consumer app have very different tails.
4. Is there a cheap guard? @supports costs almost nothing. Reach for it when the answer to question 2 is bad and the answer to question 3 is uncertain.

That order matters. A feature that degrades gracefully doesn't need the analytics check at all, and a feature that degrades badly isn't rescued by a good Baseline status.

Checking it without opening a browser

Three packages turn this into something your build can answer.

web-features is the dataset itself: the WebDX Community Group's shared catalogue of web platform features with their Baseline statuses, published as a plain npm package with no runtime.

import { features } from "web-features";

const f = features["field-sizing"];
console.log(f.status.baseline);          // "low"
console.log(f.status.baseline_low_date); // "2026-06-16"
console.log(f.status.support);           // { chrome: "123", firefox: "152", safari: "26.2", … }

status.baseline is "high" for widely available, "low" for newly available, and false for everything else. That's three lines of script away from a CI check that fails a pull request when someone uses a feature the project hasn't agreed to yet.

browserslist-config-baseline wires Baseline into the tooling that already reads browserslist targets, such as Autoprefixer, Babel and Lightning CSS:

{
  "browserslist": ["extends browserslist-config-baseline"]
}

That targets Baseline Widely available, which is a moving window: it resolves to whatever was fully supported 30 months before today's date. For a build that must produce identical output next year, pin a year set instead by adding /YYYY to the extends string — a Baseline year set is every feature fully supported in the core browsers at the end of that calendar year.

The package's data changes as browsers ship, so it needs updating like any other dependency. If you're targeting Widely available and haven't updated it in a month, it will prompt you when a browserslist-aware tool runs.

baseline-browser-mapping goes the other way: give it a browser version and it tells you which Baseline feature set that version supports. That's the package to use when you have analytics data and want to work out which Baseline year your actual audience can handle.

A note on timing

Baseline statuses move. Features join and leave as browser support and the underlying compatibility data change, and the WebDX owners group periodically reviews the definition itself — the current document records a review due on 9 September 2026. Anything you write down about a feature's status, including the tables on this site, is a snapshot. Check the data, not an article, before a release.

Sources

• Baseline status definition — WebDX Community Group, web-platform-dx/web-features
• web-features on npm — the Baseline dataset
• browserslist-config-baseline — browserslist config and its README
• baseline-browser-mapping on npm
• @mdn/browser-compat-data — the compatibility data Baseline is computed from