wpt.fyi

wpt.fyi (the web-platform-tests dashboard) displays results produced by running the open-source web-platform-tests (WPT) suite in real browsers, then publishing those runs to the dashboard. The data is not hand-entered or editorial: each result set corresponds to a specific test run against a specific browser build, and the dashboard lets you inspect the run's date and browser version so you can judge how current it is. Frequency is not a single fixed schedule — new runs appear as browser vendors and the WPT project publish them, so the practical answer is "check the run metadata for the result set you're looking at."

Where the data comes from

The chain has three parts:

1. The test suite — web-platform-tests is an open-source, cross-browser test suite maintained by the WPT project (a collaboration involving browser vendors and the wider web community). Tests live in the project's repository and cover web platform features: DOM, CSS, HTML, Fetch, WebDriver, and so on.
2. The runs — the suite is executed in actual browser engines (Chromium, Firefox, WebKit/Safari, and others). Each execution produces a machine-readable set of pass/fail results tied to a browser name and version.
3. The dashboard — wpt.fyi ingests those published runs and presents them as comparable result sets, so you can see, for a given feature area, how different browsers performed.

Because the tests are open source, the results are reproducible in principle: anyone can run the suite against a browser build and compare. That is the point of the project — a shared, vendor-neutral yardstick rather than each vendor's own test claims.

How often results are updated

There is no single "updated every N hours" guarantee that applies to the whole dashboard. Instead:

• Each result set is a snapshot of one run. Its freshness depends on when that run was executed and published, not on when you loaded the page.
• New runs arrive as they are produced by the participating browser projects and the WPT infrastructure. Different browsers and channels will therefore have different cadences.
• Stable vs. experimental channels are typically represented separately, so a "latest stable" result and a "development/nightly" result for the same browser can be weeks apart in age.

The practical consequence: never assume the top-line number you see is from today. Always confirm the run's date and browser version before drawing a conclusion, especially when comparing two browsers — an old run against a new one is not a fair comparison.

How to check the date and version of a result set

On wpt.fyi, result views are organized around runs, and each run carries metadata. To verify what you're looking at:

1. Open the results view for the feature or test directory you care about.
2. Locate the run selector or the run labels attached to each browser column.
3. Read the browser version and the run date/time for each column.
4. If a column looks stale, switch to a more recent run for that browser rather than comparing across mismatched dates.

A quick sanity check before citing any number: are all the columns you're comparing from runs of a similar date, and are you comparing like channels (stable to stable, experimental to experimental)? If not, the comparison is not meaningful.

What this means for reading results

• Treat each number as "browser X, version Y, run on date Z." That is the full claim the dashboard supports.
• Prefer recent, matched runs when comparing browsers; the dashboard's value is comparability, and mismatched dates undermine it.
• Use the underlying test suite for detail. If a result surprises you, the individual test files and their expected results are in the open-source WPT repository, which is the authoritative source behind the dashboard.
• Expect gaps. A browser or channel with no recent run will simply show older data; absence of a fresh run is not evidence of a regression or an improvement.

In short: wpt.fyi is a window onto published WPT runs, not a live measurement service. Its data is as current as the most recent run for the browser you're inspecting — so check the run's date and version first, and compare only runs of similar vintage.

wpt.fyi shows, for each test, how many subtests passed or failed in a given browser run. Read a result as a fraction (passes / total subtests) plus a status label, then check the run's browser version and date before drawing conclusions. Treat small differences and unstable tests as noise rather than proof of a compatibility gap.

What the numbers and labels mean

Each row in the results view corresponds to a test file, and the number shown is aggregated from the individual subtests inside it.

• Pass/fail counts: a result like 8/10 means 8 of 10 subtests passed. A test with 0 subtests is scored as a single pass or fail.
• Status categories: results are grouped into passing, failing, and other states such as timeouts, errors, or "not run." A test that errors or times out is not the same as one that fails an assertion, and the dashboard distinguishes them.
• Partial results: a test can be partially passing. Do not read a non-100% score as "the feature is broken" without checking which subtests failed.

Grouping by browser, engine, and suite

Results are organized by browser product (for example Chrome, Firefox, Safari) and by the underlying engine, and by test suite or directory. When comparing, keep the same suite and directory selected so you are not comparing different sets of tests. A directory-level summary is useful for a quick overview; drill into individual test files before making a claim about a specific feature.

Filtering and comparing across browsers

Use the dashboard's filters to narrow to a browser, a test path, or a label, then switch between browsers to compare the same tests.

1. Select the test suite or directory you care about.
2. Apply a browser filter, or open the comparison view that places browsers side by side.
3. Confirm the browser version and run date shown for each column.
4. Compare the same test rows, not the aggregate totals, when the question is about one feature.

A practical check: if Chrome shows 100% and Firefox shows 60% on the same test file, open the failing subtests to see whether they concern the same behavior or an unrelated part of the file.

Caveats: flaky and unstable tests

Some tests are flaky, meaning they pass and fail across runs without any code change. Before treating a failure as a real interoperability problem:

• Look at results across multiple runs or dates rather than a single run.
• Check whether the test is marked as unstable or expected to fail in the suite's metadata.
• Prefer a consistent pattern across runs over a one-off failure.

For example, if a test fails in one browser on one date but passes on the next run with the same version, treat it as unstable until a repeated pattern appears.

A quick reading checklist

Use wpt.fyi as evidence about test outcomes, and pair it with the browser version and run date before concluding that a feature is or is not interoperable.

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.

Yes. wpt.fyi (the web-platform-tests dashboard) lets you look up test results for a specific web feature and compare pass rates across browsers. Search for the feature or API name, open the matching test directory or run, and read the per-browser pass/fail counts. Treat the results as evidence of test conformance, not as a formal compatibility guarantee: a feature can pass all tests in a browser and still behave differently in real pages, and a feature with thin test coverage can look healthier or worse than it is.

Finding Tests for a Feature

wpt.fyi is built on the web-platform-tests (WPT) repository, where tests are organized into directories that mirror web platform areas (for example, a directory for a given API or CSS module). To locate a feature:

1. Enter the feature name, API name, or CSS property in the dashboard's search field.
2. Open the test directory or individual test file that matches your target.
3. Select the browser or browser channel you care about to see results for that run.

The expected result is a list of test files with per-browser status. If the search returns nothing, the feature may have no dedicated tests yet, or the tests may live under a differently named directory — try alternate names (interface name vs. spec section name) before concluding coverage is missing.

Reading the Results

Each test file shows pass and fail counts per browser. A high pass rate across browsers is a signal of interoperability; a low or uneven rate points to implementation gaps or spec ambiguity. When comparing browsers, use the same test run and the same channel (for example, stable vs. experimental) so the comparison is like-for-like. Results from experimental channels can move quickly and may not reflect what users on stable releases see.

What the Results Do and Do Not Tell You

A feature with full test coverage and consistent passes is a strong interoperability signal. A feature with sparse tests may show misleadingly clean results simply because little is being checked. Use the dashboard to spot where implementations diverge, then confirm behavior in the browsers you actually target.

Using It Alongside Other Resources

wpt.fyi is most useful as one input among several. Pair it with:

• MDN browser compatibility tables for a feature-level support summary and notes on known differences.
• Can I use for adoption and support context on widely used features.
• Your own testing on the browsers and versions your audience uses, especially for features where WPT coverage is thin.

If the dashboard shows a feature passing everywhere but your target browser still misbehaves, the tests likely do not cover the specific behavior you depend on — that gap is the thing to investigate next.