Skip to main content

Web Platform Baseline

Baseline is a shared indicator maintained by the W3C WebDX Community Group that tells developers whether a web platform feature works across all major browsers. Instead of manually cross-referencing compatibility tables, you check a single label: is it Baseline or not? It ships with two clear tiers that map directly to risk tolerance. Learn more at the official Baseline page.

The Two Tiers​

StatusDefinitionWhen to use
Newly availableSupported in the latest stable release of all core browsersB2B apps, managed environments
Widely available30 months after becoming Newly availablePublic-facing sites, broad audiences

The clock for Newly available starts on the date the last browser ships support. Once 30 months pass without regressions, the feature graduates to Widely available — meaning even users who lag behind on updates are covered.

Features that haven't reached Baseline yet are labelled Limited availability. Using them requires feature detection and fallbacks.

The Core Browser Set​

A feature must ship in all of these to qualify as Baseline:

BrowserEnginePlatforms
ChromeBlinkDesktop, Android
EdgeBlinkDesktop
FirefoxGeckoDesktop, Android
SafariWebKitmacOS, iOS

Since Chrome and Edge share the Blink engine, they typically ship features together. In practice, the gate for Baseline is usually Safari or Firefox landing support last.

Checking Baseline Status​

  • webstatus.dev — dashboard of all web platform features with Baseline status, filterable by year and category.
  • MDN Web Docs — shows a Baseline badge at the top of each feature page. Green = Widely available, blue = Newly available, grey = Limited.
  • Can I Use — browser support tables now include Baseline status banners.
  • web.dev/baseline — official landing page with annual highlights and explainers.

Using Baseline in Your Projects​

Browserslist Configuration​

The browserslist query language supports Baseline directly. This cascades to Autoprefixer, PostCSS, and Babel — any tool that reads browserslist will respect it.

For a public-facing site:

package.json (excerpt)
"browserslist": ["baseline widely available"]

For a B2B app with managed browsers:

package.json (excerpt)
"browserslist": ["baseline newly available"]

Linters and IDE Support​

The <baseline-status> Web Component​

You can embed a live Baseline status widget in internal docs or design-system pages:

<script
  type="module"
  src="https://cdn.jsdelivr.net/npm/baseline-status@1.0.4/baseline-status.min.js"
></script>

<baseline-status featureId="container-queries"></baseline-status>

The component is also available via npm (baseline-status) for bundled setups.

Practical Decision Guide​

ScenarioRecommended tierRationale
B2C / public websiteWidely availableNo control over user browsers
B2B / managed browsersNewly availableBrowsers updated regularly
Library / framework authorsWidely availableBroadest audience
Progressive enhancementNewly available + feature detectionEnhance for modern, fall back gracefully
tip

Define your Baseline tier early during requirements gathering. See Requirement Engineering for how to capture browser-support constraints alongside functional requirements.

note

For examples of using modern web APIs in practice, see the Browser APIs section — it currently covers URLPattern, sendBeacon, forms, and the HTML Sanitizer API.

How Baseline Works Under the Hood​

  • The web-platform-dx/web-features GitHub repo is the canonical source of truth for feature definitions and status.
  • It consumes compatibility data from @mdn/browser-compat-data.
  • Features are grouped at a developer-meaningful level — for example, "CSS Grid" is one feature rather than dozens of individual properties.
  • The W3C WebDX Community Group manages the project, with participants from Google, Apple, Microsoft, Mozilla, and Igalia.

Resources​