Capability Resources

Before I knew the right tools, my workflow for checking browser support was embarrassing. Google the API name. Open three different Stack Overflow answers. Hope one of them mentioned Safari.

There is a better way. Six tools cover every compatibility question you will encounter while working with browser APIs. After running the maturity tier check, these are what you reach for next.

MDN Web Docs

MDN is the closest thing the web has to an official API reference. Despite the "Mozilla" in the name, it has been a nonprofit effort for years -- covering every browser, not just Firefox. If you want to know what parameters a function accepts, what the return value looks like, or what happens when you call it without the right permissions, MDN is the starting point.

Every API page ends with a browser compatibility table. It is not as granular as Can I Use (no version ranges), but it is enough to see at a glance whether Safari supports something.

Can I Use

Can I Use is the fastest first check for capability support. Search any API name, get a table showing support across Chrome, Firefox, Safari, Edge, Samsung Internet, and mobile browsers -- with the exact version each browser started supporting it.

This is where you confirm whether you are dealing with a green API or a light-green one. If the Safari row is empty or red, you know the iOS situation before writing a single line of code.

Chrome Status

Chrome Status answers the question MDN and Can I Use don't: what phase is this API in for Chrome?

You can look up any API by name and see the full release history -- when it first shipped behind a flag, when it entered an origin trial, when it became stable, and which Chrome version first included it. This is the right tool when you are trying to understand whether an API you found in a blog post is actually production-ready or still experimental.

The release timeline view on Chrome Status also shows what is shipping in the current stable version, the beta, and canary -- so you can track what is coming without waiting for release notes.

web.dev

web.dev is where the Chrome team publishes code-rich guides on capabilities. Unlike MDN (which explains the API spec) or Can I Use (which shows compatibility tables), web.dev shows you how to build something real with the API.

It covers most of the capabilities in this series with full code examples, common patterns, and production considerations. It is the right place to go after you have confirmed an API exists and want to see how other developers have actually used it.

The WebKit Blog

Safari has no equivalent of MDN or web.dev. If you want to know what an upcoming Safari release includes, or why Safari's implementation of an API differs from Chrome's, the WebKit blog at webkit.org/blog is the only official source.

This used to be poorly maintained -- sparse updates, months of silence. The situation has improved significantly. The team now publishes detailed release notes for each Safari Technology Preview, and the major releases get proper documentation.

For any API where Safari's behavior matters, the WebKit blog is a required read. MDN's compat table will tell you if the API is supported. The WebKit blog will tell you what quirks to expect.

Baseline

Baseline is a multi-vendor initiative from Google, Mozilla, and Apple that produces an annual list of capabilities that are safe to ship on all major browsers.

The idea is simple: instead of checking browser-by-browser support yourself, you look for the Baseline badge. If an API is Baseline 2024, it was available on all major browsers by end of 2024. You can ship it today without conditional logic or fallbacks.

ExpandSix Reference Tools for Web Capability Work

Baseline status appears directly on MDN pages and on web.dev articles, so you do not need to look it up separately. You will see it more and more as the initiative matures.

The Workflow in Practice

These tools complement each other, not replace each other.

• MDN first -- understand what the API does and its basic compat status
• Can I Use second -- confirm the exact browser version support, especially for Safari and mobile
• Chrome Status -- if the API feels new or unstable, check whether it is actually in stable Chrome
• Baseline -- if you need a simple "is this safe to ship everywhere" answer, look for the badge
• WebKit blog -- when Safari support matters and MDN's table says "partial" or the behavior seems off
• web.dev -- when you are ready to build and want real code examples

No single tool tells the whole story. The combination takes 60 seconds and replaces an hour of Googling.

With the tooling covered, the next step is a quick map of the APIs this series won't cover -- the ones you already know exist. Knowing what's in and what's out of scope is part of building a useful mental model of the web capabilities landscape.

The Essentials

1. MDN covers "how to use it." Can I Use covers "which browsers and versions." Chrome Status covers "what phase Chrome is in." Together they answer most questions in under a minute.
2. The WebKit blog is the only official source for Safari-specific behavior -- MDN compat tables are often incomplete for Safari edge cases.
3. Baseline is the multi-vendor answer to "is this safe to ship everywhere." If an API has a Baseline year badge, you can ship it without per-browser detection for that year's browsers.

Further Reading and Watching

• Baseline: The simple way to check browser compatibility (Chrome for Developers) -- official walkthrough of how the Baseline initiative works and where to find Baseline badges on MDN and web.dev
• Chrome Platform Status -- chromestatus.com -- the live release tracking dashboard; search any API name for its full Chrome history