What is the web-platform-tests dashboard (wpt.fyi)?

Updated

wpt.fyi is the public results dashboard for web-platform-tests (WPT). It is a viewer, not a test runner: it shows how different browsers and browser engines pass or fail the shared WPT test suites, so you can judge cross-browser interoperability of a web feature before relying on it. Use it when you want evidence about support across engines rather than a single vendor's compatibility table.

What the dashboard actually shows

WPT is a cross-browser test suite for the web platform. Browsers run those tests in their own CI, and wpt.fyi aggregates the results. The dashboard lets you:

  • Look up a test or directory of tests and see pass/fail results per browser.
  • Compare results across browsers and across browser versions or channels.
  • Filter by test status to find failures or unstable results.
  • Inspect individual test results, including subtests, to see which specific behavior diverges.

Because results come from real test runs, the dashboard reflects behavior of specific builds, not a marketing claim of "supported."

How to use it for a decision

  1. Find the feature's tests. Search for the relevant test path or feature name. WPT tests are organized by spec area, so results cluster around the feature you care about.
  2. Pick the browsers and versions to compare. Select the engines you ship to. Comparing stable channels tells you about current users; comparing experimental channels tells you what is coming.
  3. Read pass rates with context. A high pass rate across engines suggests good interoperability. A split result means behavior differs and you may need a fallback or feature detection.
  4. Drill into failures. Open failing tests and subtests to see whether the gap is a core behavior or an edge case. A single failing subtest is a different risk than a whole directory failing.
  5. Verify in your own environment. The dashboard is evidence, not a guarantee. Confirm the behavior in the browsers you actually target.

Example task

Suppose you plan to depend on a newer layout or API behavior. Search the test directory for that feature, compare stable results for the engines you support, and note which subtests fail. If one engine fails a core subtest, plan a feature-detection path or a fallback before shipping.

What it is not

  • Not a testing tool. You do not run your own tests there; it displays results of the WPT suites.
  • Not a spec. Passing tests indicate conformance to tested behavior, not a complete reading of the specification.
  • Not a substitute for your own testing. Your app's combination of features, polyfills, and target versions still needs verification.

Common sticking points

  • Version drift. Results are tied to specific builds; a result from an older run may not match current releases. Check which version a result belongs to.
  • Test coverage gaps. A feature may be partially tested, so a clean pass rate does not prove full interoperability.
  • Interpreting failures. Some failures reflect test instability or environment differences rather than a real browser bug. Look at the subtest detail before drawing conclusions.

For anyone deciding whether a web feature is safe to adopt across browsers, wpt.fyi is the fastest way to see shared, test-based evidence — provided you read the results at the right version and check the failing details rather than the headline number alone.