# Fyrd/caniuse: the raw browser support data behind caniuse.com > A JSON repository with no application code, holding the feature support tables that caniuse.com renders and that build tooling reads. **Fyrd/caniuse** — Raw browser/feature support data from caniuse.com - Repository: https://github.com/Fyrd/caniuse - Website: https://caniuse.com - Stars: 5,874 · Forks: 1,417 - Language: JSON - License: CC-BY-4.0 - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/fyrd-caniuse ## A repository with no code in it Fyrd/caniuse is described in its own README as raw data from the caniuse.com support tables, and that description is accurate in the strict sense that the repository contains almost no executable logic. The project language is JSON, the license is CC-BY-4.0 rather than an open source software license, and the repository tree starts with `.editorconfig`, `.gitattributes`, `.gitignore` and `.npmignore` before reaching any actual data. It has 5,874 stars and 1,417 forks, which tells you how many builds read from it, but the stars belong to the dataset's usefulness rather than to any program in the tree. The README states the repository serves two purposes: letting anyone contribute updates to the site's support data, and giving other projects access to that same data. Everything else is downstream of those two lines. The second purpose is the one most people in this repository actually care about, because the file at the centre of it, `fulldata-json/data-2.0.json`, is what tooling fetches when it needs to know whether a CSS property or JavaScript API is safe to use. One detail in the README is worth pausing on for anyone reasoning about accuracy. It says some of the data shown on caniuse.com comes from browser-compat-data rather than from this repository, meaning the site aggregates and this repository holds the caniuse-maintained portion. That distinction matters when the two sources disagree. ## Which file to consume and which to ignore The README names `fulldata-json/data-2.0.json` as the file to use and calls `data.json` available for backwards compatibility. That is a clear instruction, but the tree shows the data is split into several directories that the README does not enumerate, so the shape is wider than the two files most people will ever touch. Alongside `data.json` and `sample-data.json` at the root, there are directories named for the granularity of the data they hold. The directory names do most of the explaining. `features-json/` holds one entry per feature, which is the shape you want when a build tool needs to answer a single question about a single feature. `fulldata-json/` holds everything at once, which is what you want when you are building the table caniuse.com renders. `region-usage-json/` holds usage share information, the data behind any statement about what percentage of users a browser commands. `validator/` holds the tooling that checks the files. The `sample-data.json` file at the root is worth knowing about even if you never ship it. In a dataset this size, a small valid example is the cheapest way to understand the record shape without downloading the full file, and it is the file to read first if you are writing a parser. ## Packaging for npm consumption The repository is published to npm as `caniuse-db`, and the package manifest is explicit about what it ships and how it checks itself. The name differs from the repository name, which trips people up the first time they install it. The version string, 1.0.30001810 at the current manifest, tracks data recency rather than a semver release cadence you can reason about as software. The files array in the manifest is the part that answers the practical question of what you get after install: ```json + "scripts": { + "validate": "node validator/validate-jsons.js" + }, + "files": [ + "CONTRIBUTING.md", + "data.json", + "features-json", + "fulldata-json", +``` That list is published alongside the data itself, so the validator ships with the package. Someone consuming the data from npm has the same checking tool available that the maintainers run, which is unusual for a dataset and removes the usual argument about whether a given copy of the file is well formed. The manifest also carries the author contact and the CC BY 4.0 license declaration, so the attribution requirement travels with the artifact rather than living only on a web page. ## Contributing to the tables The README's first listed purpose is contribution, and it points at `CONTRIBUTING.md` as the file to read before doing anything. That is the whole of the guidance given at this level, which means the repository is deliberately shallow in documentation and puts its weight into the data and the validator instead. The activity level is real. The repository is not archived and the last push was on 2026-09-15, so the browser data was being refreshed right up to near the present. At the same time the open issue count stands at 979, which is a large queue and tells you that contributions land into a busy review process rather than a quick merge. Anyone planning to submit a correction should expect to go through it rather than assume the change is trivial. The model here is worth naming because it explains the design. Browser support data is not derived from a spec and cannot be computed; it comes from testing each feature against each browser and recording the result. That makes the data a set of observations, and observations need humans who are willing to check and argue about them. The repository is a record of those observations, which is why its shape is raw JSON with a validator rather than a schema-driven pipeline. ## Licensing and attribution in practice The CC BY 4.0 license is the single most consequential fact about this dataset for anyone shipping a product, and the README is unusually clear about the obligation: mention somewhere that the source is caniuse.com. There is no separate commercial licence to negotiate and no per-use fee. Attribution is the entire price. That makes the license question almost trivial and the accuracy question less so. If your build fails on a user agent because this file said a feature was unsupported, the useful next step is a correction through the contributing path rather than a local patch, because a local patch fixes only your build and a correction fixes everyone reading the file. That is a genuine practical argument for contributing rather than forking the data. The manifest restates the license inside the published package, which means the attribution requirement is visible to someone inspecting node_modules without ever reading the README. Given how many tools depend on this file, that is a reasonable courtesy from the maintainer, and it is also a reminder that the data carries a real obligation even when it arrives as an npm dependency. ## Where the README stops This README is short, and the honest reason is that the repository is a dataset rather than a system. It gives you the licence, the attribution requirement, the two files that matter, and two links: the contributing file and the author contact. It does not document the record schema inside `data-2.0.json`, and it does not describe what each of the JSON directories contains beyond the names. The caniuse.com site itself is the layer above. The README points at it for the rendered tables, and the site's own documentation is where you would look for how a feature name maps to a data key. For a consumer building a compatibility warning in a bundler plugin, the practical route is to read `sample-data.json`, use `fulldata-json/data-2.0.json` as the source, and treat `CONTRIBUTING.md` as the authority on proposing changes. The project is created and maintained by Alexis Deveria, as both the README and the manifest author field state, and the repository is sponsored by Browserstack. That single-person maintenance is the fact most worth carrying away from this dataset: it is widely consumed, actively updated, and the person deciding what goes into it is one person, which is an argument for pinning versions and being gentle in issues. ## Conclusion The useful thing about this repository is that it settles a question other tools leave vague: which file holds the data, and under what terms you may use it. `fulldata-json/data-2.0.json` is the one to consume, `data.json` exists only for older callers, and the CC BY 4.0 licence asks for nothing more than a mention of caniuse.com. There is no runtime, no build output and no schema documentation beyond `CONTRIBUTING.md`, so treat it as a well-maintained snapshot with 979 open issues rather than a contract. Read the contributing file before opening a pull request, and pin a version, since the package version encodes how current the browser data is. ## FAQ ### How does caniuse work? caniuse.com holds a database of feature support records, one per feature, covering which browser versions support it and since when. This repository is the raw JSON behind those tables, and the site renders from it. Some data shown on the site comes from browser-compat-data instead, so the repository holds the caniuse-maintained portion rather than every figure you see. ### Which file in the Fyrd/caniuse repository should my build read? The README names fulldata-json/data-2.0.json as the file to use, since it includes all support data. The root data.json is kept for backwards compatibility with older consumers. The per-feature directory is the more targeted option when a tool only needs to answer questions about specific features. ### Can I use caniuse data in a commercial product? Yes, under CC BY 4.0. The README asks for one thing in return: mention somewhere that the source is caniuse.com. There is no commercial licence to buy and no per-use fee, and the licence is restated inside the published npm package so the obligation travels with the data. ### What does the validator in the caniuse repository check? The manifest wires npm run validate to node validator/validate-jsons.js, and the validator directory is listed in the published files, so the checking tool ships with the package. That means a consumer from npm can run the same structural check over the data that the maintainers run before it reaches the site. ## Sources - [Fyrd/caniuse on GitHub](https://github.com/Fyrd/caniuse) - [Issues](https://github.com/Fyrd/caniuse/issues) - [License: CC-BY-4.0](https://github.com/Fyrd/caniuse/blob/main/LICENSE) - [Project website](https://caniuse.com) - [README](https://github.com/Fyrd/caniuse/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fyrd-caniuse