cssdb: a ranked database of where each CSS feature stands

What the dataset is, and the problem it was built to fix

cssdb is a list of CSS features and their positions in the process of becoming implemented web standards, and the documentation puts it plainly: it ranks CSS features by stages that reflect the real-life stability of new CSS features.

The argument for a separate ranking system rather than reusing the CSSWG's own stages is set out in the README. You can read an inside view of the CSSWG to learn about the official and unofficial development stages of CSS specifications. In reality, specifications and browser implementations happen out of sync. For example, there are stable CSS features missing in all browsers, while other CSS features developed outside the CSSWG have appeared in browsers behind flags. This is too ambiguous for the web development community, and a more accountable process is desired.

That paragraph is the whole reason the project exists, and it is a better argument than it first appears. The CSSWG stage model describes how a specification is progressing through a standards process. What a developer needs to know is different: can I use this in production today, and where. A feature that is at CSSWG stage 4 but shipped in no browser is less usable than a feature that is at stage 2 and shipped everywhere behind a flag with a long history of no changes.

So the stages in cssdb are a different measurement. They are about stability in the wild, and they are the basis for a tool that wants to decide what to emit.

The two audiences are separated in the documentation as well. If you came to update the status of a CSS feature or add a new one, the pointer is to CONTRIBUTING.md. If you came to learn about the stages, the pointer is to STAGES.md.

The project is MIT-0 licensed, which is the no-attribution variant of MIT, the primary language is JavaScript, the homepage is cssdb.org, and the recent releases are v8.12.0 from 2026-09-30, v8.11.0 from 2026-08-30 and v8.10.0 from 2026-08-15, with the last push to the repository on 2026-10-19.

How the data is published, and what a consumer actually gets

The published artefact is a JSON file, and the packaging shows exactly how it is meant to be consumed.

The package is cssdb at version 8.12.0, with type module, and the two build outputs are cssdb.json and cssdb.mjs. The main field points at cssdb.json and the module field at cssdb.mjs, and the files list contains only those two, so the published package is the data and nothing else.

The export map is the part worth looking at:

  "exports": {
    ".": {
      "import": "./cssdb.mjs",
      "require": "./cssdb.json",
      "default": "./cssdb.json"
    }
  }

So an ES module import gets the module build and a CommonJS require gets the JSON, with the JSON as the default for anything else. The result is that a tool can depend on cssdb and read the data without a parser, without a build step and without a runtime dependency of its own.

The site is a separate concern from the data, and the scripts show how the two are kept apart. The start script runs a preview site task, and the build script renders the site, with prestart and prebuild hooks that run the whole preparation chain first. The preparation chain is the interesting part: preparesite runs populatedb, then create-badges, then buildcss.

populatedb is a task that populates the database, and prepublishOnly runs it on its own, which means the published data is regenerated from the source of truth in src/ rather than edited in the published file. create-badges writes the stage badges and the baseline badges, and buildcss compiles the stylesheet with PostCSS, with a separate script that lints the stylesheet through stylelint.

The tests follow the same discipline. The test script runs the CSS test and the JSON test in sequence, the CSS test is a stylelint run over the source stylesheet, and the JSON test is a node script that validates the data, with a separate script for checking documentation links.

So the repository is a pipeline: a source of truth in src/, a generator, a validation step, and a published JSON file that is a build product. That structure is what lets a dataset be reviewed and diffed like code.

The stage definitions, and the contribution workflow

Two documents carry the meaning, and the project is explicit that they are where a reader should go.

STAGES.md is the stage reference, and it is the piece that makes the dataset usable rather than merely interesting, because a rank is only useful if everyone agrees on what the ranks mean. The README's framing of the project as a more accountable process is a claim about documentation: the stages are defined in a document that is versioned in the same repository as the data, so a change to the meaning of a stage is a reviewable change next to the data that uses it.

CONTRIBUTING.md is the workflow for changing a status or adding a feature, and the README puts both workflows at the top of the page, before any of the explanation, which tells you that keeping the data current is the main activity of the project.

That currentness is the point. A staged feature database is only useful if the stages are right, and a stage that lags reality is worse than no stage at all, because a build tool will happily emit a feature on the strength of it. The release cadence supports that view: three releases between mid-August and the end of September, at v8.10.0, v8.11.0 and v8.12.0, which is a rate that suggests ongoing corrections rather than a big rewrite.

The repository is organised to support the workflow. There is a src/ directory holding the source data, a tasks/ directory with the individual scripts, a utils/ directory for shared helpers, a public/ directory for the site, a cssdb.settings.json for the configuration, and a.nvmrc for the Node version. The CHANGELOG.md records the history and SEMVER.md documents how the version number relates to the content, which is worth reading for a data package, because the question a consumer actually has is whether a patch release can change the meaning of an entry.

Who maintains it, and how the project is funded

The package metadata names three contributors, with Antonio Laguna listed first and with a website, and Romain Menke and Jonathan Neal after him. The organisation is csstools, which is a wider group of CSS tooling projects, and the funding section lists an OpenCollective for csstools and GitHub sponsors.

That arrangement is typical of the CSS tooling ecosystem, and it says something about how a project like this is sustained. cssdb has no commercial sponsor and no product, so the funding is community money and the maintenance is whoever has an incentive to update a stage that their own tool depends on. The incentive structure is actually reasonable for this kind of artefact, because a build tool that emits a CSS feature and finds it unstable in a browser has a direct interest in correcting the entry, and that person is a user of the data as well as a potential contributor to it.

The same group maintains other CSS tooling, and the shared infrastructure is visible in the repository conventions. The files use tabs in the package manifest rather than spaces, the editor configuration is checked in, there is a CODE_OF_CONDUCT.md and a SECURITY.md alongside the CHANGELOG.md, and there is a pull request workflow with a test badge for the test script.

The project is also published to npm under the name cssdb, with the version badge pointing at the registry, and the site is at cssdb.org. The pairing of a registry package and a human-readable site is what makes the dataset usable: a build tool consumes the JSON, and a developer reads the site to understand what the stages mean before deciding to depend on it.

Where cssdb is the wrong tool

The first limit is that it is not a browser compatibility table, and the confusion is easy to make. cssdb ranks features by stage, and the stages are about the standards process and real-world stability, not about which browser ships which version of which feature. A developer asking which browsers support a given property needs caniuse or the MDN compatibility data, and cssdb will not answer it.

The second is that the stage model is deliberately coarse. It is a single ordered scale, and a scale loses information: a feature that is stable in one browser and completely absent in another has to be given a single position, and a tool that emits it on the strength of that position may produce something that breaks in a browser the tool never checked. The project acknowledges that specifications and implementations are out of sync, and the stage system is a way of summarising that rather than resolving it, so a consumer that needs per-browser certainty has to get it elsewhere.

The third is the operational shape of the data. The published file is generated from src/ by a task, and the published version is a snapshot. A build that depends on a pinned cssdb version inherits a snapshot of the web's feature stability at the moment of pinning, and the newer the pin, the more likely it is that a stage has moved. That is the intended behaviour, but it means a cssdb upgrade is a change to what your build emits, so it belongs in the same review as any other output change.

The fourth is the maintenance question. The data is maintained by a small group with community funding, and the release history shows regular updates, but there is no guarantee that a feature you rely on will be noticed when it changes status, and no notification mechanism. The stage of a feature is a fact about the world that the dataset records at a point in time, and the same is true of any other compatibility dataset.

And the fifth is that stages are a proxy for judgement. A tool that emits a feature because cssdb says it is stage 3 is making a decision that the dataset author made on the community's behalf, with whatever evidence they had. That is a reasonable arrangement, and it is the reason the project insists on an accountable process and published stage definitions, but it is still somebody else's judgement baked into your build output.

Editorial conclusion

cssdb is worth depending on if your tooling makes decisions about which CSS features to emit, because the stages are defined against the real behaviour of browsers rather than against a spec's status, and because the dataset is a plain JSON file you can read, vendor and diff. It is the wrong tool if you want per-browser support data, and it is the wrong tool for a one-off feature lookup. Before you wire it into a build, check three things: that the version you pin matches the stage definitions you were planning against, since the stage model is documented in STAGES.md and evolves with the dataset, and the project publishes a SEMVER.md that explains how the version relates to the content; that you keep the stage data and the browser support data separate, because the whole premise of the project is that the two disagree, and a tool that merges them back together loses the distinction that makes the dataset useful; and that you note the licence, which is MIT-0 rather than MIT, so there is no attribution requirement on the data you redistribute.

Frequently asked questions

Official sources

1. csstools/cssdb on GitHub
2. License: MIT-0
3. Project website
4. README
5. Releases