# compat-table: ECMAScript Compatibility Tables for ES5, ES6, and Beyond > compat-table is the GitHub repository behind the browser and compiler compatibility tables at compat-table.github.io, covering ES5, ES6, ES2016+, ESNext, and non-standard features, with a build script that regenerates the HTML pages from JavaScript test files. **compat-table/compat-table** — ECMAScript compatibility tables - Repository: https://github.com/compat-table/compat-table - Website: http://compat-table.github.io/compat-table/ - Stars: 4,508 · Forks: 933 - Language: JavaScript - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/compat-table-compat-table ## What compat-table Tracks and Who Uses It compat-table is a project that records which ECMAScript features are supported by which browsers, JavaScript runtimes, and transpilers. It covers ES5, ES6 (ES2015), ES2016 and later, and ESNext (features not yet in a finalized spec), as well as non-standard features. The live site at compat-table.github.io shows each feature as a row and each environment as a column, with green, red, or partial-support cells. The primary users are JavaScript developers who need to know whether a specific language feature is safe to use without a polyfill or transpilation step, and transpiler authors who use the tables to track coverage for tools like TypeScript, Babel, and Traceur. The repository itself is also a contribution target: browser teams and community members submit result updates as the browsers ship new features. ## How the Test Data Files and Build System Work The test data lives in four JavaScript files: data-es5.js, data-es6.js, data-esnext.js, and data-non-standard.js. These files define the feature tests and record the results for each environment. Editing one of these files is how you add a new feature, update an existing result, or add a new environment column. The build step regenerates the HTML output from these source files: ```bash node build.js ``` This writes the static HTML pages to the corresponding directories (es5/, es6/, es2016plus/, esnext/, esintl/, non-standard/). The tests themselves are written in a consistent style: ES6 tests must be written in ES3 except for the single ES6 feature under test, so the test code itself does not accidentally pass in environments that lack the feature. Test code is placed in multi-line comments to prevent syntax errors in environments that do not support the tested feature; the build script wraps the code in an eval call inside a try block, so the tests do not need to catch errors explicitly. Most tests carry a significance rating: large features are worth 1 point, medium features 0.5, small features 0.25, and tiny features 0.125. This rating affects the overall support percentage displayed for each platform. ## Running Compatibility Tests Against Node.js The repository includes a script for testing a Node.js binary against the ES6 tests. First install the dependencies and build a fresh HTML file: ```bash npm install node build.js ``` Then run the test script with the Node.js executable you want to evaluate: ```bash node . ``` The script prints color-coded results to stdout. Green indicates correct support, cyan indicates support that incorrectly requires strict mode, and red indicates no support. The README notes that the Node.js test script is currently hard-coded to display ES6 results only, not ES5 or ESNext results. If you need to test Node.js against other spec versions, that requires adapting the script manually. ## Testing Compilers and Transpilers The repository can also generate compatibility pages for compilers such as TypeScript, Babel, and Traceur. Install the compilers under test: ```bash npm install npm update ``` Then generate the compiler test pages: ```bash node build.js compilers ``` This creates HTML files under es6/compilers/. The README recommends opening these files in a browser with minimal native ES6 support, such as an older Safari or Opera release, so that native support does not mask compiler failures. The README also notes a structural limitation: some tests rely on runtime eval results to verify that certain constructs are syntax errors. These tests cannot be compiled and will always fail on the compiler pages. Compiler support for those features must be checked manually rather than from the generated tables. The package.json dependencies list includes @babel/standalone, typescript, core-js-bundle, traceur, es5-shim, es6-shim, and several other transpilers and shims, so running npm install pulls in a large set of packages. ## Limitations of compat-table as a Data Source The compatibility data in compat-table is manually maintained. When browser vendors ship updates or change behavior, someone must update the corresponding data file and submit a pull request before the tables reflect the change. There is no automated pipeline that reads browser version changelogs and updates the records. The repository is structured around a static site generator (build.js producing HTML) rather than a structured data format like JSON. This means consuming the compatibility data programmatically requires parsing HTML or reading the raw data-*.js files, which are JavaScript source files with embedded test code, not clean data exports. Teams who need machine-readable ECMAScript compatibility data as a library dependency often choose MDN browser-compat-data instead. Some tests in the Node.js runner cannot be run against browsers directly. The browser-facing pages require a human to open each HTML file in the target browser and record the results. The README does not describe a headless browser automation step for collecting new browser results. ## compat-table vs. MDN Browser Compatibility Data MDN browser-compat-data is the other widely used source for JavaScript feature compatibility. The two projects have different structures. MDN browser-compat-data is published as an npm package (@mdn/browser-compat-data) with a JSON schema designed for programmatic consumption. It is the data source behind the compatibility tables embedded in MDN documentation pages and is used directly by tools like Browserslist and eslint-plugin-compat. compat-table focuses on ECMAScript specification coverage across more environments, including JavaScript engines like Rhino, Nashorn, DukTape, and GraalVM that MDN does not track. It also covers transpiler output, which MDN does not. If you need compatibility data for a JavaScript engine that is not a browser, compat-table is the more likely source. If you need compatibility data as an npm dependency for build tooling, MDN browser-compat-data is the more natural fit. ## Maintenance, Repository Structure, and License The last push to the repository was on 2026-05-05. The project is hosted on GitHub Pages from the gh-pages default branch. There are no GitHub releases; updates are deployed by building and committing new HTML files to the branch. The repository has a GOVERNANCE.md file, indicating there is some documented process for project decisions beyond a single maintainer. The license could not be automatically determined from the repository metadata. The repository contains a LICENSE file. Review that file before reusing any code from the repository in other projects. The project traces its origin to the kangax/compat-table repository (reflected in the package.json repository URL) and has been maintained under the compat-table GitHub organization. ## Conclusion compat-table is the right resource for JavaScript developers who need detailed, feature-level compatibility data across browsers, runtimes, and transpilers, and who want to understand or contribute to how that data is collected. The repository is the right starting point if you need to add a browser result or correct an existing one: fork it, edit the data file, run node build.js to verify the output, and submit a pull request. Teams who need compatibility data in machine-readable form for tooling integration should evaluate MDN browser-compat-data first, as it is the more commonly adopted source for that use case. Before using any code from this repository, verify the license in the LICENSE file: the license could not be automatically determined. ## FAQ ### How do I update a browser compatibility result in compat-table? Edit the appropriate data file (data-es5.js, data-es6.js, data-esnext.js, or data-non-standard.js), run node build.js to regenerate the HTML output, and verify the change looks correct in the generated pages before submitting a pull request. ### What does the compat-table test significance rating mean? Each test has a significance rating that affects the overall support percentage calculated for each platform. A large feature is worth 1 point, medium is 0.5, small is 0.25, and tiny is 0.125. Landmark features like classes or promises are rated large; minor parameter additions are rated tiny. ### Can I use compat-table compatibility data as an npm dependency? The repository is structured as a static site generator, not a data package. The raw data is in JavaScript source files mixed with test code, not a clean JSON export. For programmatic consumption in build tooling, MDN browser-compat-data (@mdn/browser-compat-data) provides a JSON schema designed for that purpose. ## Sources - [compat-table/compat-table on GitHub](https://github.com/compat-table/compat-table) - [Issues](https://github.com/compat-table/compat-table/issues) - [Project website](http://compat-table.github.io/compat-table/) - [README](https://github.com/compat-table/compat-table/blob/gh-pages/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/compat-table-compat-table