You check its Baseline status. Baseline is a shared label that tells you whether a web feature works across all the major browsers, and for how long it has done so. Instead of reading four separate support tables and guessing, you read one word: limited, newly available, or widely available.
For years this was the most annoying question in front-end work. Someone would find a lovely new CSS property, ship it, and then discover a chunk of visitors saw a broken layout. The answer was always "check Can I Use", which gave you a grid of percentages and left the actual decision to you.
Baseline replaced the percentages with a decision. That sounds small. In our work it changed how quickly we say yes to new platform features, and it removed a lot of arguing from code review.
Baseline is a browser support standard maintained by the WebDX Community Group. Google's web.dev describes it this way: "Web Platform Baseline brings clarity to information about browser support for web platform features." It assigns each feature one of three statuses so you can tell at a glance whether the feature is production ready.
The project sits on top of a shared catalog called web-features. The W3C announced on 13 March 2025 that the WebDX Community Group had mapped most keys from the browser-compat-data project into "1000+ higher-level features" in web-features, which it called "a first nearly complete catalog of web features". That catalog is the thing Baseline labels.
The practical effect is that one definition now shows up in many places. You see the same status badge on MDN Web Docs, on web.dev, and inside linting tools. Everybody is reading from the same list instead of maintaining a private opinion about what is safe.
Newly available means the feature works in the latest stable version of every core browser, so it is interoperable right now. Widely available means 30 months have passed since that interoperable date. Anything that has not reached all core browsers yet is labelled limited availability. Those three words carry the whole system.
Google's web.dev defines newly available as "the feature is supported by all of the core browsers, and is therefore interoperable", and widely available as "30 months have passed since the newly interoperable date. The feature can be used by most sites without worrying about support."
MDN Web Docs states the same threshold in different words, saying features marked widely available "have a consistent history of support in each of the Baseline browsers for at least 2.5 years", while newly available features "work in at least the latest stable version of each of the Baseline browsers, but may not work with older browsers and devices."
That 30 month gap is the clever part. It is a proxy for the long tail of people who have not updated their browser or cannot update their phone. A feature that shipped everywhere last month is genuinely interoperable and still genuinely risky, and Baseline lets you say both things at once.
Baseline looks at Chrome, Edge, Firefox, and Safari. MDN counts seven entries because it separates desktop and mobile, listing Safari on iOS and macOS, Chrome on Android and desktop, Firefox on Android and desktop, and Edge on desktop. A feature has to work in all of them before it can be called newly available.
Notice what is not on that list. There is no Internet Explorer, no Samsung Internet, no Opera Mini, and no in-app webview. Those browsers mostly track the same engines, so support usually follows, but Baseline does not promise it.
This matters more than teams expect. If a meaningful share of your traffic comes through an embedded browser inside a social app, Baseline is a starting point rather than a guarantee. We still check real analytics before we commit to a feature on a client build.
Because Can I Use answers a different question. It tells you which browser versions support a feature and what percentage of users that covers. Baseline tells you whether to ship. One is data, the other is a recommendation, and most teams were quietly bad at turning the first into the second.
We watched the same conversation happen on every project. Somebody would say 94% support is fine. Somebody else would say our audience skews older. Neither person had a rule, so the loudest opinion won and the codebase ended up inconsistent.
Baseline gives a team a rule they can write down once. Our own default is that widely available features go in without discussion, newly available features need a fallback, and limited availability features need a genuinely good reason. That single sentence saves us more review time than any tooling change we have made.
It also travels well outside engineering. A founder or marketer can understand "this is widely available" without knowing anything about browser engines, which makes scope conversations much shorter.
The fastest way is MDN Web Docs. Every feature page now shows a Baseline badge at the top with the status and the date it reached that status. The web.dev Baseline pages give the same information organised by year, and the web-features package on npm exposes the data if you want to check it in a script.
Two real examples show how the labels read in practice. The CSS :has() selector is Baseline widely available, and MDN notes it has "been available across browsers since December 2023". The Popover API is Baseline 2025 and newly available, with MDN stating it has worked "across the latest devices and browser versions" since January 2025.
Those two features are only about a year apart in interoperability, and the labels tell you to treat them completely differently. We would use :has() in a client build without a second thought. We would use the Popover API with a plan for what happens when it is missing.
There is tooling for the automated version too. The baseline-browser-mapping package on GitHub converts Baseline targets into browser lists, which means you can feed a Baseline year straight into Browserslist and have your build tooling agree with your design decisions.
Ship them when the feature degrades gracefully, and wait when it does not. That is the whole test. If a browser without support simply misses a nicety, newly available is fine. If a browser without support gets a broken layout or a dead button, wait for widely available or write a fallback.
This is really just progressive enhancement with a better label attached. Build the thing that works everywhere, then layer the new feature on top for browsers that have it. We wrote about that mindset in our post on progressive enhancement and why it still matters, and Baseline is the missing piece that tells you which layer a feature belongs in.
Some features make this easy by design. The View Transitions API is a good example, because a browser without it just navigates normally and nobody notices anything is missing. Layout features are the risky ones, since a missing layout feature is visible to everyone.
Our honest position is that most teams are too conservative here, not too reckless. Waiting 30 months to use something that already works in every current browser costs you real capability, and it usually means shipping more JavaScript to do a job the platform already does.
It usually means shipping less code. A lot of the JavaScript in older projects exists to reproduce things browsers now do natively. Once a feature is widely available, the polyfill, the utility library, or the custom script that replaced it can come out, and the page gets lighter.
Container queries are the clearest case we deal with. Teams built entire resize-observer setups to make components respond to their container instead of the viewport. Now the platform does it, which is why we treat CSS container queries as a normal part of a build rather than an experiment.
Less code is not a vanity metric. Every kilobyte of JavaScript you delete is parse time, execution time, and main thread work you are not spending, and all three show up in Core Web Vitals. Baseline is the permission slip that lets you delete it with confidence.
It does not tell you whether the feature is a good idea. Baseline measures support, not quality, accessibility, or performance. MDN says directly that Baseline is not a substitute for accessibility, usability, performance, or security testing, and that it may not account for older devices or assistive technology.
That caveat gets skipped a lot. A feature can be widely available and still be the wrong tool for your page, or still need extra work to be usable with a screen reader. Baseline shortens the compatibility conversation. It does not replace the design conversation.
It also says nothing about bugs. Interoperable does not mean identical. Two browsers can both support a feature and still render it slightly differently, which is why we keep real device testing in every build regardless of what the badge says.
Write down your team's Baseline rule and put it in the repository. One sentence is enough. Decide what happens with widely available, newly available, and limited features, then hold the line. The value of Baseline is not the data, it is having a rule everybody already agreed to before the argument starts.
After that, do an audit in the other direction. Look for polyfills and helper scripts in your codebase, check whether the feature they replace is now widely available, and delete the ones that have become redundant. That is usually the fastest performance win hiding in an older project.
If you want a second pair of eyes on which features your build is carrying that the browser now handles for free, we are happy to take a look. It is one of the first things we check when we inherit a site. Let's talk, and you can find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.