Published: September 12, 2025
Emerging tooling for Baseline helps you determine which web features are safe to use in your web applications today. These tools, such as linters and IDE features, use a data source of web platform features that contains data about their support in modern browsers.
The Web Platform Status Dashboard is one data source for these features and provides a queryable HTTP API. Querying this data source on demand is not practical for all tools. For many tooling use cases, the web-features
npm package is a more reliable and practical version of web feature data that you use locally. This guide will show you how to use the web-features
package to develop your own Baseline tools.
Get started with the web-features
package
First, install the package as a dependency in your project:
npm install web-features
Once installed, import one or more named exports from the web-features
package into your project:
import { features, groups, browsers, snapshots } from 'web-features';
Depending on your goals, you might not need all of these exports. These exports provide the following information:
features
: An array of objects, where each object represents a web feature. This is the export you will most frequently use.browsers
: An array of objects describing browsers.groups
: An array of objects that defines a logical grouping of features. These are useful if your goal is to target a subset of web platform features, such as those for CSS, JavaScript, and more specific groupings.snapshots
: Contains the ECMAScript versions of corresponding JavaScript features, such as ES2023, ES2022, and other ECMAScript versions.
The features export provides the following properties for building Baseline tooling:
id
: The unique identifier for the feature. For example, the identifier for CSS Grid is"grid"
. Note: this is not a property within the data object. It's the object key.compat_features
: An array of individual BCD keys included in the feature.name
: The human-readable string of the feature's name, such as"Container Queries"
.description
: A short description of the feature.group
: The group in which the feature belongs. This corresponds to group data found in thegroups
export.baseline
: The feature's Baseline status. This can be one of three values:false
: The feature's status is Limited availability."low
": The feature is Baseline Newly available."high
": The feature is Baseline Widely available.baseline_high_date
: The date the feature became Baseline Widely available. Note: this is not available if the feature is not Baseline Widely available.baseline_low_date
: The date the feature became Baseline Newly available. Note: this is not available for Limited availability features.
The following example is the full data object for the CSS subgrid feature:
"subgrid": {
"caniuse": "css-subgrid",
"compat_features": [
"css.properties.grid-template-columns.subgrid",
"css.properties.grid-template-rows.subgrid"
],
"description": "The subgrid value for the grid-template-columns and grid-template-rows properties allows a grid item to inherit the grid definition of its parent grid container.",
"description_html": "The <code>subgrid</code> value for the <code>grid-template-columns</code> and <code>grid-template-rows</code> properties allows a grid item to inherit the grid definition of its parent grid container.",
"group": "grid",
"name": "Subgrid",
"spec": "https://drafts.csswg.org/css-grid-2/#subgrids",
"status": {
"baseline": "low",
"baseline_low_date": "2023-09-15",
"support": {
"chrome": "117",
"chrome_android": "117",
"edge": "117",
"firefox": "71",
"firefox_android": "79",
"safari": "16",
"safari_ios": "16"
}
}
}
The groups
export provides data on feature groupings with the following structure:
id
: The unique identifier for the group. For example, CSS features have an ID of"css". Note: this is not a property within the groups object. It's the object key itself.name
: The human-readable name of the group.parent
: The ID of the group's parent group. This is not available if the group doesn't have a parent.
Examples
The following examples show how to use the web-features package
to get the data you need to build Baseline tooling.
Look up the Baseline status for a specific feature
import { features } from 'web-features';
function getBaselineStatus (featureId) {
return features[featureId]?.status.baseline;
}
This example represents the most direct use case for the web-features
package, where you specify a feature's ID to get its Baseline data available in the status.baseline
property. This property tells you if a feature is Limited availability, Newly available, or Widely available. In the latter two cases, you also have access to dates that describe when the feature reached a certain Baseline threshold.
Look up the Baseline status for a specific BCD key
BCD stands for browser-compat-data
, a project maintained by MDN to catalog support for features across browsers. A BCD key corresponds to a granular feature, like a specific CSS property value or a behavioral subfeature defined by the spec.
The web-features
project groups related BCD keys into the compat_features
array for each feature. Sometimes you need the Baseline status of one BCD key, rather than the overall Baseline status for the entire feature. For example, if you build a CSS linter and need to know if a property-value pair is compatible across major browsers, the feature-level data is too coarse. This happens because the package aggregates each feature over all its constituent BCD keys, and some keys have better browser support than others.
To look up the Baseline status of a BCD key, use the compute-baseline
package:
import { getStatus } from 'compute-baseline';
function getBaselineStatus (featureId, bcdKey) {
return getStatus(featureId, bcdKey);
}
For example, the output of getBaselineStatus('outline', 'css.properties.outline')
is:
{
"baseline": "low",
"baseline_low_date": "2023-03-27",
"support": {
"chrome": "94",
"chrome_android": "94",
"edge": "94",
"firefox": "88",
"firefox_android": "88",
"safari": "16.4",
"safari_ios": "16.4"
}
}
Sort features by their Baseline status
This example iterates through every feature in the features object and sorts each one into an array by its Baseline status.
import { features } from "web-features";
const webFeatures = Object.values(features);
const widelyAvailable = webFeatures.filter(feature => {
return feature.status.baseline === 'high';
});
const newlyAvailable = webFeatures.filter(feature => {
return feature.status.baseline === 'low';
});
const limitedAvailability = webFeatures.filter(feature => {
return feature.status.baseline === false;
});
This example illustrates how to work with the status.baseline
property in your tooling. For example, you could use this approach in a web application to display a list of all web features by their Baseline status.
Find all features within a group
So far, all the examples shown use the features
export, but the groups
export organizes all features logically within groups. This means you could, for example, find all features that are part of View Transitions:
import { features, groups } from 'web-features';
const groupKeys = Object.keys(groups);
const featuresData = Object.values(features);
const viewTransitionsGroup = groupKeys.find(groupKey => {
return groupKey === 'view-transitions';
});
const viewTransitionsFeatures = featuresData.filter(feature => {
return feature.group === viewTransitionsGroup;
});
The intersection between the features
and group
exports lets you narrow your search for web features by the group they belong to.
Putting it all together
You can use the lookups to build useful tools, for example to create a CSS linter.
CSS linters evaluate at-rules, pseudo-elements, properties, and property-value pairs. For your Baseline linter, look up the status of each token by its BCD key, not by its parent feature.
A parser like CSSTree tokenizes CSS, breaking a stylesheet into an abstract syntax tree (AST). The following example shows a CSS rule that uses a generic class selector and a style declaration:
.foo {
word-break: auto-phrase;
}
The AST would look something like this:
{
"type": "StyleSheet",
"children": [
{
"type": "Rule",
"prelude": {
"type": "SelectorList",
"children": [
{
"type": "Selector",
"children": [
{
"type": "ClassSelector",
"name": "foo"
}
]
}
]
},
"block": {
"type": "Block",
"children": [
{
"type": "Declaration",
"important": false,
"property": "word-break",
"value": {
"type": "Value",
"children": [
{
"type": "Identifier",
"name": "auto-phrase"
}
]
}
}
]
}
}
]
}
When you find a property declaration as you walk through the AST, map that property name to its corresponding BCD key to check its Baseline status. BCD categorizes CSS properties under the css.properties
object, so the corresponding BCD key is css.properties.word-break
.
Then, use that BCD key as a value in getBaselineStatus
, from the compute-baseline
package.
// Leaving the feature ID as null for simplicity. It still works!
const status = getBaselineStatus(null, 'css.properties.word-break');
The Baseline status for the word-break
property is as follows:
{
"baseline": "high",
"baseline_high_date": "2018-03-30",
"baseline_low_date": "2015-09-30",
"support": {
"chrome": "44",
"chrome_android": "44",
"edge": "12",
"firefox": "15",
"firefox_android": "15",
"safari": "9",
"safari_ios": "9"
}
}
The "high"
Baseline status indicates the property is widely available, so your linter does not need to issue a warning. Next, examine the property's value.
The AST shows that the value of this property is auto-phrase
. To get the corresponding BCD key, add the value to the parent property's BCD key: css.properties.word-break.auto-phrase
.
In this case, compute-baseline
returns that the status of the word-break: auto-phrase
property-value pair is not Baseline:
{
"baseline": false,
"support": {
"chrome": "119",
"chrome_android": "119",
"edge": "119"
}
}
Use the information in this linter example to warn the developer that this property-value pair is not Baseline. This warning ensures that the developer knows it won't work as expected across the major browser engines.
Real-world examples
The previous examples show basic uses of the web-features
package. There are already a number of tools taking advantage of this data. For example:
eslint-css
uses theweb-features
package in itsuse-baseline
rule to lint for specific features.- The hovercards in Visual Studio Code use the
web-features
package to show Baseline information for CSS features and HTML features. - MDN uses the
web-features
data in the banners on most feature pages (for example,abs()
) to communicate their Baseline status.
There are more examples out there of how this data source can be used to build Baseline tools—and we hope that your project becomes one of them!