SQLite Sharpens Mozilla's Browser Compat Data, But Who Needs It?
Simon Willison's new tool transforms sprawling JSON into a lean database. It's clever, but is it necessary?

Takeaways
- ›Converts Mozilla's browser compatibility JSON to a lean SQLite database
- ›Automated GitHub Actions workflow keeps data current and accessible
- ›Most useful for teams working with SQLite or needing complex queries
- ›Value depends on existing workflows; potential may outweigh immediate impact
Browser compatibility data is crucial, but often unwieldy. Mozilla's MDN offers a wealth of information, but it's trapped in a labyrinth of JSON files. Simon Willison's browser-compat-db aims to cut through this complexity by packaging it all into a single SQLite database. It's an elegant solution, but it begs the question: Is this solving a real problem, or just reshuffling data?
The core concept is straightforward: take Mozilla's mdn/browser-compat-data repository and distill it into a 66MB SQLite file. This database now encapsulates compatibility information for web APIs, HTML, CSS, and more in a format that's trivial to query.
Here's a taste of what you can do:
SELECT * FROM compat_data
WHERE api_name LIKE 'CSS.properties.%'
AND browser_name = 'chrome'
AND support_type = 'added'
ORDER BY version_added DESC
LIMIT 5;
This query instantly reveals the most recently added CSS properties in Chrome, a task that would require significantly more effort with raw JSON.
Willison's approach is clever:
GitHub Actions automates the database creation and hosting, ensuring the data stays current. The resulting file is pushed to a separate branch, available via GitHub's CDN with open CORS headers, a small but crucial detail that enables direct access from web applications.
But let's cut to the chase: Does this tool solve a genuine problem?
For developers comfortable with JSON and existing tools built around Mozilla's data format, browser-compat-db might be an unnecessary abstraction. It doesn't add new information; it merely reshapes existing data.
However, for teams that frequently query compatibility data or want to integrate it into SQLite-based tools (like Datasette), this could be a significant time-saver. The ability to run complex queries across the entire dataset opens up new possibilities for analysis and tooling.
The project's true potential lies in its role as a building block. By providing a standardized, easily queryable format, it could spawn an ecosystem of tools and integrations that make browser compatibility checks more data-driven and smooth.
browser-compat-db is a niche tool that solves a real, if limited, problem. It's not groundbreaking, but for the right developer or team, it could remove just enough friction to make a meaningful difference in cross-browser development. Its success will hinge on the community's response and the tools built on top of it.
Ultimately, Willison's project is a reminder that sometimes the most valuable innovations aren't in creating new data, but in making existing information more accessible and actionable. Whether that's worth the extra layer of abstraction is a question each developer will have to answer for themselves.
Related reads
sqlite-utils 4.0rc2 Explained: Bugs Caught, Improvements by AI Assistant
4 min read
sqlite-utils 4.0rc1: Migrations and Nested Transactions Explained
5 min read
HTML Table Extractor: Converts Web Tables to CSV, JSON, Markdown
3 min read
LiteRT.js Explained: Google's Native AI Runtime for Browsers
5 min read
llm-coding-agent 0.1a0: Explained, Python Library for AI Coding Assistance
3 min read
Datasette Agent SQL Prompt Flaw: How Optimization Backfires
3 min read
Reported and explained by AI·Reporter.