What Baseline describes
Baseline summarizes the availability of web platform features across a core browser set: Chrome on desktop and Android, Edge on desktop, Firefox on desktop and Android, and Safari on macOS and iOS. It covers features such as HTML elements, CSS capabilities, JavaScript syntax, and browser APIs rather than assigning one compatibility label to an entire website.
The WebDX Community Group defines the model. A feature has limited availability before it meets the cross-browser criteria. It becomes Baseline Newly available when it is interoperable across the core set. After 30 months it becomes Baseline Widely available, a conservative signal intended for broad production use. Baseline year labels provide stable feature sets for policies and tooling.
What the label does not prove
Baseline is a compatibility summary, not a release decision by itself. It does not cover every embedded webview, older browser version, specialist browser, or device in an audience. Newly available says current core browsers implement the feature; it does not say that the site's users have already upgraded to those versions.
The label also does not establish accessibility, usability, security, or performance. A supported API can still be applied in an inaccessible control, create excessive main-thread work, or fail with assistive technology. MDN explicitly warns that Baseline does not replace those forms of testing. Teams still need task-based tests and audience evidence.
Choose a project target
A public content site may choose Widely available features for its essential path and progressively enhance with newer capabilities. A controlled enterprise application may adopt Newly available features sooner because supported browser versions are known. A product with verified audience data can choose a Baseline year that balances reach with the cost of older implementations.
Write the target as a policy: which journeys it covers, which Baseline status or year is acceptable, how audience data can modify the decision, and who approves exceptions. Avoid saying only that the project supports modern browsers. That phrase cannot guide a developer evaluating a feature or a tester selecting environments.
Evaluate a feature in context
Check the feature's Baseline status and detailed compatibility data. Determine whether it is essential to content or task completion, whether unsupported browsers ignore it safely, and whether a simpler native pattern meets the need. For CSS, an unsupported declaration often falls away cleanly; a JavaScript API called without detection may stop the whole enhancement.
Prefer capability detection over browser-name checks. CSS feature queries can isolate enhanced presentation, while JavaScript can test for an API before using it. A fallback should preserve the outcome, not necessarily reproduce every visual detail. If a polyfill is considered, assess its payload, maintenance, security, and fidelity rather than assuming it erases the compatibility decision.
Connect policy to tooling
Baseline data is available through MDN, web.dev, the Web Platform Dashboard, and the web-features data project. Current tooling can express Baseline targets in Browserslist and surface feature status in editors, linters, developer tools, and Lighthouse. This makes the policy visible while code is written and reviewed instead of relying on a late manual audit.
Tool warnings need context. A limited feature used for a nonessential enhancement may be acceptable, while a newly available feature on a critical path may require a fallback. Record the decision near the implementation and include the relevant path in cross-browser tests. Automation should expose the trade-off; the product team still owns it.
Maintain a focused testing matrix
Test the essential journeys in the current core browsers and in any additional environments shown by audience or contractual requirements. Include keyboard and assistive-technology checks, small screens, zoom, reduced motion, and failed or delayed resources. Compatibility means more than a page looking similar in screenshots.
Review the target on a scheduled cadence and when evidence changes: a new Baseline release, a material audience shift, a platform deprecation, or an important feature crossing the support threshold. Keep exceptions dated and owned. Baseline is most useful when it turns a moving browser landscape into a clear, revisable engineering policy.
Sources & further reading
Technical references checked on 17 September 2026.