# The Interop Project: measuring whether browsers agree with each other > The Interop Project is a yearly collaboration between browser engine vendors that picks a handful of web standards, writes a metric out of them, and scores every participating browser by running the shared web-platform test suite. The interesting part is what it refuses to do. It will not define new standards, it will not accept a feature that cannot be tested automatically, and it ranks proposals by evidence of developer pain rather than by enthusiasm. **web-platform-tests/interop** — web-platform-tests Interop project - Repository: https://github.com/web-platform-tests/interop - Website: https://wpt.fyi/interop - Stars: 529 · Forks: 37 - Language: JavaScript - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/web-platform-tests-interop ## What the project is The Interop Project is an ongoing effort to make the web more interoperable in key areas, prioritised by user and web developer needs. It is part of the web-platform-tests project, the main test suite for the web platform, and it is worked on by the Interop Team. The stated purpose is to improve interoperability significantly for the benefit of users and web developers, and the mechanism is described plainly: the goal is to improve the web by making it easier to make websites and web apps that work in every browser or browser engine at the same time. This is done by increasing the amount of interoperability between browsers, when each browser engine has implemented the same technology the exact same way, as bug-free as possible. That last phrase is the whole idea. The web's central problem is not that features are missing, it is that they are present and behave differently, and the cost of that is paid by every developer who has to write a workaround for one engine. The project's premise is that a shared standard plus a shared test suite plus a public scoreboard changes the incentives of the engine teams, who each have their own priorities and their own release schedules. The primary language is JavaScript, the licence is not a standard identifier, the default branch is main, and the homepage is wpt.fyi/interop. The last push was on 2026-10-16 with the project not archived, and the repository publishes no GitHub releases, which is right for a project whose output is a yearly cycle rather than a shipped artefact. The repository layout is the year folders. There are 2021/, 2022/, 2023/, 2024/, 2025/, 2026/ and 2027/, so the current iteration is 2026 with 2027 already open, and each year holds the focus areas, the proposals and the results for that cycle. Alongside them are charter.md, which defines how the team operates, proposal_guide.md, scripts/ for the tooling, and web-features.json, which is the shared feature list the metric is computed from. ## How the score is produced The mechanism is a metric built out of a set of web technologies that the participants collectively believe are important to improve interoperability, and that metric publicly keeps track of the work by using automated tests to score how much progress each participating browser has made reaching the shared goals. So the scoreboard is not a survey and not a review. It is a test result. Every participating engine runs the same tests from the shared suite, and the number of passing tests in the selected areas becomes the comparison. The framing of the project is worth reading carefully, because it is unusually explicit about what it is not. There are many fantastic ideas about what the web could become, but the Interop Project is not the place to begin making those dreams a reality. It is a place to focus on interoperable implementations of ideas that have already been defined in detail in web standards, and it focuses on interoperability through the use of automated tests to evaluate whether or not a particular browser matches what the web standard says it should be doing. The key phrase is that the tests already exist. The project does not write a new conformance suite for each focus area; it selects areas from the existing web-platform-tests corpus, which is what makes the comparison meaningful, because the tests are not written by the project for the purpose of scoring. The rationale for having a metric at all is that browser engineering teams have an effectively unlimited amount of work they could focus on, and the project provides incentives to focus on the specific and practical work that will have the most positive impact on the web platform in the coming year. That is a mechanism for aligning several organisations with different commercial priorities around a shared, publicly visible measure, and the public dashboard is the incentive. Today the browsers have made a commitment to implement web technology according to a shared web standard, created in organisations such as the W3C or the WHATWG, where technologies such as CSS and HTML are officially defined. The Interop Project exists to make that commitment measurable. ## The two gates a focus area has to pass The Scope section states two hard requirements, and they are what make the project tractable. The first is that everything chosen for the next year must be defined in a sufficiently mature standards-track web specification. If there is no web standard, then there is no definition of what a particular technology should be doing. The Interop Project is not an organization for defining web standards, and that work is important and must happen in the appropriate bodies, not here. The second is that everything chosen must be testable using automated tests on existing testing platforms. A proposal cannot be accepted if there are no automated tests to evaluate conformance to the web standard, if it is not possible to test the technology being proposed, or if the tests would need to run in environments that are not yet available on the Web Platform Tests infrastructure, with the example given being that in 2022 and 2023 testing on mobile operating systems was not possible. That second gate is more restrictive than it first appears, and the mobile example shows why. A feature that only exists on one platform cannot be scored, so it cannot be a focus area, even if it is important. The cost of that rule is that some genuine interoperability problems stay invisible, and the project has a mechanism for that: if there is a particular blocker making it hard to test a certain feature, that could make for a good Investigation Project proposal, and ideas about how the WPT and Interop testing infrastructure could be improved can also be proposed as Investigation Projects. So the project has an escape hatch for the cases its own rules exclude. That is a detail worth noticing, because a project with hard gates and no escape hatch would simply accumulate a queue of unfixable proposals, and an escape hatch that takes the form of improving the test infrastructure turns the exclusion into a work item. The two stated requirements for focus area proposals restate the gates in proposal form. The feature must have a mature-enough web standard from an established standards development organization such as IETF, Khronos Group, TC39, WHATWG or the W3C. And it must have high quality tests in WPT or Test262, with Test262 being the ECMAScript test suite, which is the standard way to test the JavaScript language rather than the platform around it. ## How proposals are ranked, and by what evidence The prioritisation guidance is the most concrete part of the documentation, and it is a list of evidence sources rather than a list of opinions. Beyond the two requirements, areas where web developers have had problems using them should be prioritised, whether that is because of differences between browsers or because they are not implemented in all browsers. The listed sources of information include issues filed in the Chromium, Gecko or WebKit bug trackers, complaints about the feature in public discussions on sites like Stack Overflow, ranking as a high-demand feature or as a pain point consistently in polls and surveys of web developers, and documented examples of sites or libraries working around the fact that a feature is missing or not interoperable. That last source is the one that distinguishes this from a popularity contest. A workaround written by a library author is evidence of a real problem that has already cost somebody time, and unlike a survey response it is a concrete artefact. When assessing existing web technology, the guidance adds that it can be helpful to assess how often the technology is being used currently, but that one should also consider whether important technology might not be in popular use due to lack of interoperability. The data sources listed are browser use counters, usage recorded via HTTP Archive crawls, and the number of mentions on developer resources like Stack Overflow. The caveat is the important part. A feature can be unused because nobody needs it, or because nobody can use it reliably across browsers, and those two cases look identical in the usage counters. So the usage data is a tie-breaker rather than a ranking, with the interoperability explanation always on the table. And then four values that are not measurements at all. The feature has to have a positive impact on accessibility, on internationalisation, on privacy and on security. Those are judgements, and they are the only place in the process where a qualitative argument decides anything. The result is a prioritisation process that is evidence-led but not purely mechanical, which is the right balance for a project that has to produce a consensus list several organisations will agree to work against. ## How to evaluate it, and what to watch There are four things to consider, and the first is that this is a coordination project rather than a piece of software. The output is a public scoreboard, not a library you can install. The dashboard is at wpt.fyi/interop-2026 for the current cycle, with a per-year README in the 2026/ folder, and the charter and proposal guide in the repository describe how the process runs. So if you want to influence what browsers work on next year, the entry point is the proposal process rather than the code. Second, the self-imposed limits are the feature. The project will not define standards, it will not score a feature that cannot be tested automatically, and it will not accept a technology that lacks a mature standards-track specification. That is a narrow scope, and the README is explicit that the project is not the place to turn big ideas about the web into reality. For a standards body it would be the wrong venue; for a prioritisation mechanism it is exactly right. Third, the score is only as good as the tests, and the tests only cover what somebody wrote a test for. The mobile testing example from 2022 and 2023 makes the point: a platform gap that nobody can test is a platform gap the project cannot see. So when you read a high score and conclude that a browser is interoperable, you are reading a statement about the tested surface. Fourth, the cycle structure. The year folders show this is annual, with 2027 already open while 2026 is in flight, and each year has a README and a set of focus areas. The value of the mechanism is the repetition. A single year of shared focus moves a set of behaviours into agreement, and the next year starts from the new baseline. That is a slow process, but it is the one that actually changes what ships in browsers. The feedback route is a GitHub issue on the interop repository for bugs or unclear process, and an email address for questions and advice, which is a sensible split between reporting a defect in the process and asking for guidance on it. ## Conclusion Follow the Interop Project if you want to influence which parts of the web platforms agree with each other next year, because the proposal process is the only place a proposal can enter, and a year folder is a public record of what was chosen and why. Do not treat the dashboard as a complete measure of interoperability, since it only reflects behaviour covered by existing automated tests, and a feature nobody can test is invisible to the project by design. Before you file a proposal, check the two hard gates, a mature standards-track specification and high quality tests in WPT or Test262, because a proposal that fails either will not be accepted however much evidence you attach to it, and if you are blocked by a testing limitation rather than by the technology itself, the Investigation Project route is where that belongs. ## FAQ ### What is the Interop Project? It is an ongoing effort to improve interoperability between browsers in key areas, prioritised by user and web developer needs. It is part of the web-platform-tests project and is worked on by the Interop Team, and its stated purpose is to improve the web by making it easier to build sites that work in every browser at the same time. ### How is browser interoperability actually measured? Through a metric built out of a set of web technologies the participants collectively believe are important, evaluated with automated tests from the shared Web Platform Tests suite. The metric publicly tracks how much progress each participating browser has made toward the shared goals, so the scoreboard is a test result rather than a survey. ### What are the requirements for a feature to become an Interop focus area? It must be defined in a sufficiently mature standards-track web specification from an established body such as IETF, the Khronos Group, TC39, WHATWG or the W3C, and it must have high quality tests in WPT or Test262. A proposal cannot be accepted if there are no automated tests to evaluate conformance, or if the tests could not run on the available WPT infrastructure. ### How are Interop focus area proposals prioritised? Areas where web developers have had problems using a technology should come first, whether because of differences between browsers or because it is not implemented everywhere. The named evidence sources are issues in the Chromium, Gecko and WebKit trackers, complaints in public discussions such as Stack Overflow, high-demand or pain-point rankings in developer surveys, and documented examples of sites and libraries working around a missing or non-interoperable feature. ### What values guide the Interop prioritisation beyond the evidence? Four, and they are judgements rather than measurements: the feature has to have a positive impact on accessibility, on internationalisation, on privacy and on security. There is also an explicit caveat that usage data should be weighed carefully, since important technology might be in low use because of poor interoperability rather than lack of demand. ## Sources - [Issues](https://github.com/web-platform-tests/interop/issues) - [Project website](https://wpt.fyi/interop) - [README](https://github.com/web-platform-tests/interop/blob/main/README.md) - [web-platform-tests/interop on GitHub](https://github.com/web-platform-tests/interop) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/web-platform-tests-interop