MDN data turns CSS and Web API definitions into JSON you can query

A dataset of definitions rather than of documentation pages

MDN data is a repository of general data for Web technologies, maintained by the MDN team at Mozilla and published as the npm package mdn-data. What it holds is structured JSON describing CSS and Web APIs, not prose and not documentation pages. The distinction matters for how you use it. A CSS property in this dataset is an object with a name, a syntax, a type, a description and localisation strings, which means a linter, a code editor, a documentation site or a parser can read it directly instead of scraping prose from a web page. Two consumers are named in the project documentation: MDN Web Docs itself, which uses the data to build information boxes and sidebar navigation, and external tools, with the CSSTree CSS parser given as an example. The topics list the repository as css, data, json and json-data, which is an accurate summary of a package whose consumers are mostly programs rather than people.

The api folder carries inheritance, the css folder carries syntax

The repository is organised by broad area, with a top-level directory for each, and inside each one or more JSON files hold the data. The api directory contains data about Web APIs, and the specific thing it records is API inheritance, covering interface inheritance and mixin implementations. That is the one piece of structural information the api area holds, which tells you it is not a full API reference but the graph that shows which interfaces extend which. The css directory covers considerably more ground: at-rules, functions, properties, selectors, syntaxes, types and units. Splitting the CSS data by category like that is what makes it usable by tools, because a consumer can load only the properties file and skip the selectors. The repository also documents how to update the CSS JSON database and points to the CSS data README for the schema of each file, so the shape of every record is written down somewhere rather than being implicit in the JSON.

l10n strings ship with the data, and the npm files list is narrow

Localisation is not a separate translation pipeline bolted on afterwards. The l10n folder holds the localisation strings used in the JSON files throughout the repository, so a consumer that renders descriptions gets translated text out of the box rather than English placeholders it has to map itself. The npm package definition shows how that is packaged. The published files list is short and explicit:

  "files": [
    "api/index.js",
    "api/*.json",
    "css/index.js",
    "css/*.json",
    "l10n/index.js",
    "l10n/*.json"
  ],

The entry point is index.js at the root of the package, and the areas are also exposed per directory through their own index.js files. The consequence for a consumer is that anything outside api, css and l10n, the documentation and the contributor guides, is not shipped in the npm tarball. That is a deliberate packaging choice rather than an oversight, and it also means the package stays small even though the repository itself contains prose and schemas.

Checking the data: the lint script is the test suite

There is no build step to speak of, because the package ships JSON that is already in its final shape. What the project does have is a validation step, and the package manifest wires it up so that the test script is the lint script:

  "scripts": {
    "lint": "node test/lint",
    "test": "npm run lint"
  },

The linter runs from the test directory and depends on ajv and better-ajv-errors, which is a schema validator for JSON. That tells you what happens when a data file gains a field nobody defined: the schema check fails and the contribution is rejected. Contributors are asked to familiarise themselves with the schema for the data they are editing and to send a pull request, with CONTRIBUTING.md holding the detail, and there is a separate REVIEWING.md for the review side. There is also a lint workflow badge in the README, so the same check runs in continuous integration. For a maintainer of a fork, that script is the entry point to check that a local edit has not broken the shape of the data.

The deprecation notice points at w3c/webref

The most important line in the documentation is the note at the top. The maintainers state that they are in the process of deprecating the mdn/data package in favour of w3c/webref, and they ask people who depend on the project to say so in the MDN community GitHub discussions, on the platform category. This changes how you should treat the repository. It is not a project with an uncertain roadmap, it is one with a stated successor, and the successors name matters because webref is a different shape of project with a different scope. So a team that depends on mdn/data today has a decision to make rather than a risk to monitor: move to w3c/webref, keep the pinned npm version and accept that it will not gain new browser data, or drop the dependency. What the data is used for also changes the answer. If you want to know which properties exist and how they are spelled, this dataset still answers that. If you want to know which browsers support them, the answer lives in the separate mdn/browser-compat-data project, which the documentation lists under see also for exactly that reason.

CC0-1.0 terms and release tooling

The licence is CC0-1.0, a public domain dedication, and the manifest carries it as the package licence with the author given as Mozilla Developer Network. For a dataset of factual descriptions, that is about the most permissive choice available, and it removes the usual question about attribution when the data is embedded in a product. The package version is 2.37.2, and tagged releases include v2.37.0 on 2026-09-23, v2.37.1 on 2026-09-29 and v2.37.2 on 2026-10-03, with the last push on 2026-10-15. The release process is automated: the repository carries release-please-config.json and a release-please-manifest.json alongside a CHANGELOG.md, so version bumps and changelog entries are produced by tooling rather than by hand. There is a .nvmrc for the Node version, a package-lock.json for reproducible installs, and a SECURITY.md, which is the file to read if you find a problem with the data itself rather than with the packaging.

Editorial conclusion

Adopt mdn/data only for existing integrations that already consume the npm package, and plan the move to w3c/webref rather than starting new work against a dataset the maintainers are retiring. Do not adopt it as a compatibility source, because support tables live in the separate mdn/browser-compat-data project, and do not rely on it as a long term contract without reading the deprecation notice. Before you pin a version, check that the release you choose still contains the JSON files you read, since the published files list only covers api, css and l10n, and confirm whether your consumer can switch to w3c/webref without a change in how the data is fetched.

Frequently asked questions

Official sources

1. License: CC0-1.0
2. mdn/data on GitHub
3. Project website
4. README
5. Releases