Read the label at the feature level
Baseline describes support for individual web features across a core set: Chrome on desktop and Android, Edge on desktop, Firefox on desktop and Android, and Safari on macOS and iOS. The WebDX Community Group defines the model.
A feature becomes Newly available when all browsers in that set support it. It becomes Widely available 30 months after that point. Features that have not met the cross-browser requirement have Limited availability. The label applies to a feature such as a CSS property or browser API; it cannot certify an entire application.
Check the environments outside the label
A customer may use an older managed browser or an embedded webview. Baseline does not establish support for every such environment. Newly available also does not mean everyone visiting your site has installed a supporting release.
MDN explicitly separates Baseline from accessibility, usability, performance, and security testing. A supported dialog API still needs sensible focus behavior and a usable close control. A supported CSS feature can still produce unreadable content when text is enlarged.
Turn browser support into a written rule
For a public article site, a reasonable project policy could require essential reading and navigation to work with Widely available features, allowing newer CSS for optional presentation. For an internal application, the supported browser versions may be specified by the organization. Check that those versions actually receive the expected updates.
Write down the essential tasks and the environments used to test them. 'Modern browsers' leaves developers guessing. Name who can accept an exception and what evidence they need, such as audience data or a contractual browser requirement.
Decide what happens when support is missing
A decorative CSS effect can often be omitted without changing the task. An API required to open the only navigation control is a different case. Check detailed compatibility data and test the fallback behavior before treating either one as acceptable.
Detect capabilities where practical. A CSS feature query can apply an enhanced layout only when supported. A JavaScript API needs an existence check before use if the target includes browsers without it. Unsupported syntax may fail before such a check can run, so your build target also matters. If considering a polyfill, check which behavior it reproduces and what it adds to the page.
Make the policy visible during development
MDN and the Web Platform Dashboard expose feature support data. The Baseline site also documents integrations for tools including Browserslist and Lighthouse. Use the integrations that fit the project to surface compatibility questions during review.
A warning needs a decision in context. Record why a newer feature is safe for optional styling, or point to the fallback used on an essential path. An automated label cannot tell whether someone can still submit the form when an enhancement is unavailable.
Test a few complete tasks
Open the site in its supported browsers and complete the tasks named in the policy. Follow a deep link, use the navigation with a keyboard, submit invalid input, and recover from an error. Include the extra webview or managed browser if the audience requires it.
Revisit the policy when supported devices or contractual requirements change. Date each exception so it can be removed when its reason disappears. The practical benefit of Baseline is having a shared starting point for these decisions, with fewer arguments based on an undefined idea of browser support.
Sources & further reading
Technical references checked on 17 September 2026.