Baseline: A New Way to Think About Browser Support

For years, frontend developers have wrestled with an outdated question: “Which browser versions do we support?” This framing made sense when Internet Explorer dominated and browsers updated annually. Today, Chrome and Firefox release new versions every few weeks. Safari updates regularly. The old mental model no longer fits.

Web Platform Baseline offers a better approach. Instead of tracking browser versions, you track feature availability. This article explains how Baseline works, why it matters for modern browser compatibility, and how to apply it in your projects.

What Is Web Platform Baseline?

Baseline is a cross-vendor initiative backed by Google, Microsoft, Apple, and Mozilla through the W3C WebDX Community Group. You’ll find Baseline indicators on MDN, web.dev, and Can I Use.

Baseline answers a simple question: Can I use this feature safely across browsers?

It defines a core browser set:

• Chrome (desktop and Android)
• Edge
• Firefox (desktop and Android)
• Safari (macOS and iOS)

When a feature works across all these browsers, it earns Baseline status.

The Three Availability States

Baseline features fall into three categories:

Limited availability: The feature exists in some browsers but not all. Use with caution or with polyfills.

Newly available: The feature works in all stable versions of every core browser. It’s interoperable but recent.

Widely available: The feature has been in all core browsers for at least 30 months. Most users have access.

The 30-month threshold for “Widely available” isn’t arbitrary. It accounts for users who don’t update immediately, older devices, and downstream browsers that inherit from major engines. After 30 months, a feature has typically reached nearly everyone.

Why This Mental Model Shift Matters

Traditional version-based policies create problems. What does “last two versions of Firefox” mean when Firefox ships six major versions during a single project? The target keeps moving.

Feature-availability thinking solves this. Instead of asking “What browser versions do we support?” you ask “Is this feature Baseline?”

This shift offers three practical benefits:

Clearer decisions. Check MDN for the Baseline indicator. If it shows “Widely available,” use the feature confidently. No mental math about version numbers.

Better stakeholder communication. “We use features available in all browsers for 30+ months” is easier to explain than “last two versions of Chrome, Firefox, and Safari, plus Firefox ESR, plus anything above 0.5% global usage.”

Improved consistency. Teams make fewer judgment calls. The policy applies uniformly across projects.

How to Apply Baseline in Practice

Adopting Baseline follows a straightforward pattern:

For core functionality, rely on Widely available features. These form your foundation. Users without modern browsers still get a working experience.

For progressive improvements, use Newly available features with feature detection. Wrap them in @supports blocks or JavaScript checks. Users with older browsers get the base experience, while others get the upgraded version.

/* Widely available fallback */
.container {
  max-width: 100%;
}

/* Newly available enhancement */
@supports (container-type: inline-size) {
  .container {
    container-type: inline-size;
  }
}

The CSS above is a clean example of progressive enhancement. Every browser understands max-width: 100%. Browsers that also support container queries get the more capable layout. Nothing breaks for anyone.

Integrating Baseline with Your Tools

Baseline is increasingly supported in developer tooling. Browserslist now supports Baseline queries directly (for example, targeting “widely available” features or a specific Baseline year), helping keep your build tools aligned with your support policy. The browserslist-config-baseline package provides a ready-made configuration if you prefer not to write queries yourself.

ESLint’s CSS support (@eslint/css) includes a use-baseline rule that can flag properties falling outside your chosen Baseline threshold. While not perfect — it can be overly strict about progressive enhancement patterns — it signals where the ecosystem is heading.

Expect tighter integration with build tools, linters, and frameworks as Baseline adoption grows.

Baseline Is a Default, Not a Guarantee

Baseline provides a strong starting point, but it doesn’t replace judgment. Edge cases exist. A feature might be Baseline but carry a significant bug in one browser. Accessibility concerns may require testing beyond compatibility data. Enterprise environments with locked-down browsers need separate consideration.

Use Baseline as your default assumption, then verify when the stakes are high.

Conclusion

Web Platform Baseline represents a fundamental shift: from version-based support matrices to feature-availability thinking. It reduces cognitive overhead, improves team communication, and aligns with how modern browsers actually work.

Start by checking Baseline status on MDN before reaching for new features. Adopt “Widely available” as your foundation. Layer in “Newly available” features through progressive enhancement. Let the tooling catch up to support your workflow.

The question isn’t which browsers you support. It’s which features you need.

FAQs

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.