Baseline 2026 Is Not Safe to Ship
Quick answer: Baseline 2026 means every core browser shipped the feature at some point during 2026. It does not mean your users have it. Baseline's own "Widely available" bar is 30 months after that date, so the 2026 set does not clear it until 2028 and 2029. Target baseline widely available in Browserslist, lint against it, and treat the 2026 list as a watchlist rather than a shipping list.
Every January a wave of posts announces which web platform features are "now safe to use." They are all pointing at the same thing: the yearly Baseline set. And they are all quietly skipping the part of Baseline's own definition that matters most to anyone shipping to real traffic.
Baseline has two statuses, not one. The first says browsers agree. The second says enough time has passed that agreeing is worth something. Thirty months separate them. If you read "Baseline 2026" as a green light, you have skipped two and a half years of browser upgrade cycles and taken on the polyfill bill yourself.
What Baseline actually measures
Baseline is a status attached to a feature, computed from browser compatibility data rather than opinion. The web-features specification defines the low status — what web.dev surfaces as Newly available — as a feature "supported in each current stable release in the core browser set," with partial implementations excluded.
The core browser set is four engines across seven targets: Chrome on desktop and Android, Edge on desktop, Firefox on desktop and Android, and Safari on macOS and iOS. A feature that ships in Chrome, Edge and Firefox but not Safari is not Baseline. A feature that ships in Safari on macOS but not iOS is not Baseline either — the split targets are deliberate, because those two ship on different cadences and different hardware.
When the last browser lands support, the spec records a keystone date: "the last release date on which a browser introduced support for the feature." If support was pulled and reintroduced, only the later date counts. No keystone date can predate 28 July 2015, the Edge 12 release, because that is when the modern core set begins.
The yearly sets fall out of that. "Baseline 2026" is simply the group of features whose keystone date lands in 2026. It is a timestamp, not a quality judgement.
The 30-month rule is the whole point
The high status — Widely available — requires that "the feature's keystone date is on or before today's date minus 30 months," plus a Firefox ESR release-date condition. The spec is explicit that 30 months is a proxy, chosen to approximate "developer signals, estimates of browser release uptake over time, an estimate of high total market share support."
That gap exists because shipping a feature and users having it are different events. Evergreen browsers update fast on healthy consumer devices, and slowly or never on locked-down enterprise fleets, kiosk builds, old Android handsets that stopped getting system WebView updates, and iOS devices held back on an older major version. The Firefox ESR clause encodes the same reality: ESR is the channel institutions actually run, and it lags mainline by a year or more.
| Status | Condition | What it licenses |
|---|---|---|
| Limited availability | At least one core browser missing | Progressive enhancement only |
| Newly available | All seven targets shipped it | Build against it behind a fallback |
| Widely available | Keystone date 30+ months ago, ESR clause met | Ship it unguarded |
Run the arithmetic on the 2026 set and the answer is uncomfortable. A feature with a keystone date in February 2026 becomes Widely available in August 2028. One that lands in December 2026 waits until June 2029. Nothing published as "Baseline 2026" is Widely available today, and nothing in it will be for two more years.
What is actually in the 2026 set
The Baseline 2026 page currently lists 30 features, grouped into HTML and CSS on one side and JavaScript and Web APIs on the other.
HTML and CSS
Among them: field-sizing, container style queries, the :open selector, contrast-color(), @scope, shape(), custom highlights, active view transitions, text-decoration-skip-ink, and the root-relative rcap / rch / rex / ric units.
JavaScript and Web APIs
The Navigation API, WebTransport, trusted types, the Reporting API and CSP violation reports, readable byte streams, service worker and shared worker modules, Zstandard compression, Math.sumPrecise(), Iterator.concat(), Map.getOrInsert(), Intl.Locale info and branch hinting.
That is a genuinely good year. The Navigation API alone removes a category of router hackery, and web.dev marked it Newly available in a post dated 17 February 2026 once Safari and Firefox both landed it. By the 30-month clock that feature is shippable unguarded somewhere around August 2028.
Make it a build constraint, not a vibe
The reason to care about the distinction is that both statuses are machine-readable, and your toolchain will enforce whichever one you point it at. Reading a blog post and deciding a feature feels fine is the failure mode. Encoding the rule is the fix.
Browserslist understands Baseline directly. Per web.dev's guide, the queries are baseline widely available, baseline newly available, and year targets from baseline 2015 up to the current year. Appending with downstream widens the result to Chromium-based browsers outside the core set.
One line in package.json then drives every transpile and autoprefix decision downstream, which is the same reason the browser target matters so much when a bundler changes underneath you — see what actually breaks in Vite 8.
ESLint enforces the CSS side. Baseline support shipped in ESLint alongside CSS linting: install @eslint/css and use the use-baseline rule — renamed from require-baseline in 0.6.0 — with available: "widely" or "newly". Pick one deliberately and write down why.
Do this before you start shaving bytes. Chasing output size with a CSS minifier or a JS minifier is pointless if the target is wrong — the transpiler is what decides how much of that payload is polyfill in the first place.
Pick a status per surface, not per project
One global target is the wrong shape for most products. An internal dashboard your own team opens in a current Chrome can sit on Newly available and delete a pile of dependencies. A public marketing site, a docs site, or a directory read by people on whatever browser their employer allows cannot.
The honest rule: Widely available for anything anonymous traffic hits, Newly available for authenticated surfaces where you know the client mix, and Limited only behind a real feature detection branch. That maps cleanly onto how most teams already segment builds, and it is a decision worth recording next to your other framework support dates — Node's move to one major a year and Next.js caching moving to explicit opt-in both belong on the same page.
Also worth noting: Baseline only covers what the compat data covers. It will not tell you that Chrome is removing XSLT, because removals are not features gaining support. Baseline is an adoption clock, not a deprecation feed. You need both.
FAQ
Does Baseline Newly available mean a feature is production-ready?
It means every browser in the core set has shipped it in a current stable release. It says nothing about how many of your users are running that release. Baseline reserves the production signal for Widely available, which is 30 months later.
When will the Baseline 2026 features become Widely available?
Thirty months after each feature's own keystone date, so between roughly mid-2028 and mid-2029 depending on when in 2026 the last browser shipped it. There is no single date for the set.
Which browsers count for Baseline?
Seven targets across four engines: Chrome on desktop and Android, Edge on desktop, Firefox on desktop and Android, and Safari on macOS and iOS. Chromium forks such as Opera, Brave and Samsung Internet are not in the core set, though Browserslist can include them with the with downstream modifier.
How do I enforce a Baseline target in CI?
Set a Browserslist query such as baseline widely available so your build tooling inherits it, then add the use-baseline rule from @eslint/css so a stylesheet using a too-new property fails the lint step rather than shipping silently.
Why 30 months specifically?
The web-features spec describes it as an approximation drawn from developer signals, browser release uptake estimates, and an estimate of high total market share support. It is a chosen proxy, not a measurement of your own traffic — which is why your analytics should override it in both directions.
Does Baseline track removed features?
No. Baseline measures features gaining interoperable support. Deprecations and removals do not appear in it, so you still need to watch vendor deprecation feeds separately.
Set the query once, let the linter argue with you, and stop relitigating browser support in code review.