web-features: the shared catalogue behind Baseline support data

A shared vocabulary, not a feature detection library

web-features is an effort to build a shared catalog of features of the web platform. The stated purpose is to improve understanding of what web developers get and want from the web, and the method is deliberately indirect: by creating a common list of features and their definitions, the project aims to give the ecosystem one nomenclature to talk with.

That vocabulary is intended to support communication between web developers, browser vendors, standardization bodies and other ecosystem participants, which tells you the audience. This is a coordination project first and a library second. The range it covers runs from Array to Cascade Layers to Offscreen Canvas, which is a good indication of the granularity: these are recognisable capabilities that a developer might ask about, not individual CSS properties.

The work breaks into three parts. Creating feature definitions that identify and describe capabilities of the web. Generating Baseline support data, which summarises the availability of web features across key browsers and releases. And publishing the web-features npm package, which bundles feature identifiers with Baseline statuses, so a build script can ask about support without reimplementing the data.

The project is run by the W3C WebDX Community Group and contributors, which matters for how the data is treated. This is a community group rather than a working group, so the catalogue reflects consensus discussion among implementers and developers rather than a formal specification, and the repository carries a GOVERNANCE.md file that describes how decisions are made.

The practical users are the tools around the platform: browsers, compatibility databases, documentation, linters, build pipelines that decide which features to transpile.

Baseline is the product, and the feature definitions are its input

The data flow inside the project runs from definitions to statuses. A feature is defined in the features/ directory, and those definitions are the input from which Baseline support data is computed and published.

That distinction is the thing to internalise. A feature definition says what a capability is, which is a naming, grouping and description exercise. The Baseline status is the derived output that says how widely that capability is available across key browsers and releases. The project does not gather support data itself from browser vendors; it works from the compatibility information that the ecosystem already collects, and there is a dedicated test script for cross-checking against caniuse, named test:caniuse in the package scripts.

The repository layout shows the pipeline. There is a features/ directory holding the definitions, a groups/ directory for the groupings those definitions reference, a schemas/ directory containing data.schema.json, and packages/ with a compute-baseline workspace. The root holds the TypeScript core, with parse.ts, text.ts, type-guards.ts, compat-helpers.ts and assertions.ts, plus a test file next to each, and a snapshots/ directory for the test fixtures.

The compute-baseline workspace is where the derived statuses are produced, and the npm package that ships to consumers is separate again, in packages/web-features. That is a three-layer structure: definitions in, Baseline computed in the middle, a published package out.

A build step for the package is driven from the root scripts.

    "build": "tsx scripts/build.ts package",
    "feature-init": "tsx scripts/feature-init.ts",
    "update-drafts": "tsx scripts/update-drafts.ts",

The feature-init script exists for contributors, which tells you the definitions are meant to be added one at a time by hand.

The package is the part developers install, and the toolchain is strict

If you want feature identifiers, Baseline support data, or cross-references to other resources such as specifications and caniuse, the project points you at the web-features npm package, with a package README for the details. The point of the package is that it bundles identifiers together with their Baseline statuses, so a tool can consume both without stitching two data sources together.

The cross-references matter more than they first appear. A feature identifier that resolves to a specification and to a caniuse entry turns a catalogue lookup into a starting point rather than a dead end, and that is what makes the catalogue usable from a linter or a documentation generator.

The toolchain is demanding, and you should check it before you plan a contribution. The engines field requires node >=22.22.0, and the .node-version and .nvmrc files at the repository root pin the expected runtime. The code is TypeScript executed through tsx, the formatting is enforced by Prettier, and the linting by eslint with a flat config in eslint.config.js.

The test script shows the shape of the checks, and it is a long chain because the project has several independent failure modes to catch.

    "test": "npm run test:caniuse -- --quiet && npm run test:schematypes && npm run test:specs && npm run test:types && npm run test:format && npm run test:index && npm run test:dist && npm test --workspaces && npm run test:lint",

There are checks for caniuse consistency, schema types, specification references, types, formatting, index behaviour, distribution output, workspace tests and lint. The generated TypeScript types are produced from the JSON schema with quicktype, and a script rewrites them, which means the schema in schemas/ is the real source of truth for the data shape rather than the type file.

Contributing a feature means editing YAML under a documented process

The project is open to contributions, and the documentation for that lives in CONTRIBUTING.md inside the docs directory, with a separate file for the specifics. There are four kinds of contribution the project calls out: feature identification, feature definition, Baseline support statuses, and updating the status on MDN.

That last item is a reminder of how the project connects to the rest of the ecosystem. Baseline status is not a private notion invented here; it is surfaced on MDN, so a change in the catalogue changes what a developer sees on a documentation page.

The primary language of the repository is YAML, and that reflects where the work actually is. The features/ directory holds the definitions as data, which is why a change to a feature is a data edit validated against a schema rather than a code change. The schema itself, schemas/data.schema.json, is enforced by the test suite and drives the generated types.

The feature-init script scaffolds a new entry, so the intended workflow for a new capability is to generate the skeleton, fill in the fields, and let the tests check the result. There is also a remove-tagged-compat-features script and an audit-consumers script, which suggests the project pays attention to how the data is consumed downstream and to cleaning up entries that no longer map to compatibility data.

For context on the reasoning, the repository keeps a 2022-backgrounder.md file explaining why the project was started and the problems it responds to, and a towards-features.md file that reads as a working document about where the catalogue is heading.

Apache-2.0, a 3.x release line, and a separate next tag

The licence field on the repository says Apache-2.0, and the LICENSE.txt file at the root carries the terms. Apache-2.0 permits use, modification and redistribution including in commercial products, and it comes with an express patent grant and a requirement to preserve licence and notice files. Reading LICENSE.txt for the exact obligations is the sensible step, and none of this is legal advice.

The versioning picture needs a moment of attention because there are two different version numbers in play. The published npm package follows a 3.x line, with v3.42.0 on 2026-10-09 and v3.43.0 on 2026-10-15. The root package.json, which is marked private and is the monorepo workspace rather than the distributed package, carries version 0.1.0 and declares the compute-baseline workspace. So the 0.1.0 is internal tooling, and the version that matters to a consumer is the one on the npm package.

There is also a rolling tag named next, published on 2026-10-19, alongside the numbered releases. The last push to the repository was on 2026-10-19 and it is not archived, so the work is current. The distinction to make in your own pipeline is between the numbered releases and that rolling tag, because a build that tracks next can pick up a change in the catalogue, including a Baseline status change, without a version bump in your dependencies.

The catalogue is also a data product with a governance dimension, and the repository carries GOVERNANCE.md precisely because a shared vocabulary needs a process for deciding what goes in it. Contributors should read the contributing guide before a large addition, since the rules about feature identification are the substance of the project.

Editorial conclusion

Adopt web-features when your tooling needs one agreed list of web platform feature identifiers with Baseline statuses, and you would rather consume a maintained catalogue than maintain your own browser support table. Do not adopt it as a runtime feature detection library, since it describes what browsers support rather than probing what a given browser does, and note that the repository is still named with a 0.1.0 private workspace version while the published package carries its own 3.x line. Before depending on it, pin a published version such as v3.43.0 from 2026-10-15 rather than tracking the next tag, and check the schemas directory to see how a feature definition is structured before you add entries.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. web-platform-dx/web-features on GitHub