Published: May 20, 2025
When a web platform feature is implemented in every browser, it becomes Baseline Newly available. After 30 months, that feature then becomes Baseline Widely available, which is a threshold in which most websites can adopt features without compatibility concerns. This guide explains how to use Baseline, and by using data available from your website's users, how to select a Baseline target.
What is a Baseline target?
A Baseline target is a grouping of web features that developers can choose to support, based on their Baseline status. There are two types of Baseline targets: moving targets and fixed targets.
Moving targets, such as Baseline Widely available or Baseline Newly available, are targets where the set of features contained may change over time. Moving targets make sense in cases where you want the set of supported features to evolve automatically as new browser versions are released.
Fixed targets are those where the set of features does not change over time. In general, fixed targets are based on calendar years. For example, Baseline 2023 is a fixed target that contains the set of web features that became Baseline Newly available in 2023. Baseline 2023 wouldn't include features that became Baseline after 2023, which means the set of Baseline 2023 features never changes.
Fixed targets make sense in cases where predictability and determinism are paramount, but they can become out of date over time, so when using fixed targets it's a good idea to re-evaluate your target regularly.
Why choose a target?
Adoption of features on the web is held back because of compatibility concerns—and that holds the web back from being as good as it could be. Baseline not only brings clarity to the question of feature support in browsers, but it can be helpful in how it clarifies the question of when you can use certain features. By choosing a target that reflects your audience and requirements you can feel confident in using features within that target group—without needing to check individual features one by one.
Use data to select your Baseline target
Knowing the right Baseline target to select should be, when possible, a data-driven decision. When you have the data in front of you, which target to select becomes an easier and much more informed decision.
If you have Real User Monitoring data for your site, you can learn how Baseline targets map to your users. For example, if you use Google Analytics, a free way to get this information is by using the Google Analytics Baseline Checker.
To use it, you'll need to create a new exploration in Google Analytics, add some metrics and dimensions to your report, and export the report as a TSV file. This process is detailed in these instructions. When you import the TSV file into the checker, you should receive output that looks like the following:
We're starting to see other tools implement support for Baseline, that can give you a dynamic view of how much of your audience supports a given target. For example, RUMvision includes a dashboard that shows how much of your audience has support for each Baseline year.
What if I don't have support data from real users?
You might find yourself in a situation where you can't get real user data when it comes to features that are Baseline. The good news is that you can get a general idea of support for different Baseline targets through RUM Archive Insights, even allowing you to filter down to the country level. While this data won't be specific to your website's users. It's a general informational tool that demonstrates the following assumptions are generally safe:
- Newer Baseline targets—such as the current year or the year before—are likely to have the least amount of support among your users. Like any Baseline target, however, they will have better support as time passes.
- Older Baseline targets—particularly Baseline Widely available—will be well-supported. When in doubt, Widely available is an excellent target which evolves as the 30 month window progresses through time.
- Even older Baseline targets—those well beyond the 30 month Widely available window—will have the best support. While Widely available is a good default target, special use cases that require strict SLAs.
It's likely that, even if you're selecting a Baseline target that is over five years old, you're able to adopt features that you aren't using right now. In the best case scenario, you might already be using these features, but with polyfills that you might not need.
How do I enforce a chosen Baseline target in my project?
Browserslist is a commonly used method of targeting the browsers you want to support. It's used in bundlers and other associated tools such as Babel and PostCSS to decide whether certain bits of code need to be transformed or even polyfilled.
It's now possible to use Baseline with Browserslist so that, when you select a Baseline target, you can specify it as a valid Browserslist query. This ensures that the tools in your project transform code according to the target you've selected. For more information, read Use Baseline with Browserslist for more information.
What about features that don't meet my Baseline target?
After selecting a Baseline target, you might have features that you want to use, but don't fall inside that target. Baseline doesn't tell you what you should do here, and whether you want to consider using these features depends on the type of website you are building and the expected audience.
For example, ecommerce or B2B websites may be willing to have a lower support threshold and handle issues as their users support them, whereas government websites may require a high support threshold. One important rule of thumb here is that not all web features fail the same way. There's a lot of ways to categorize features on how they fail, but one way to bucket features that might be useful goes something like this:
- Enhancement: If the feature is used in an unsupported browser, the experience is not broken. The experience could possibly be degraded, but may not likely be noticeable to the user. Example:
loading="lazy". - Additive: The feature provides some additive benefits that may be noticeable—such as changes in page styling or some functionality. The difference may not be noticeable to users if the feature is unsupported, barring comparison in a browser that does support it. Example: Subgrid
- Critical: If the feature is unsupported, the user will have a negative user experience—possibly even one that's broken altogether. Example: File System Access API used as a central and necessary feature.
You might also find that particular features outside of your target have better support than you think. It's possible to understand how many of your users have support for a particular feature. Can I Use has the ability to check support for individual features against your analytics data. RUMvision also has the ability to drill down and explore feature level data if that's helpful to you.
In this way, you can use your Baseline target to reduce the number of features that you need to carefully consider. Everything inside your target you don't need to worry about. If there are one or two features outside your target that would be especially useful—you have the tools to explore further and decide whether to polyfill or use as a progressive enhancement.
Conclusion
Every web application has different requirements—from an ecommerce site that can tolerate more incompatibility concerns, to a government website that absolutely must be available and operational to as many users as possible. These are calculations you have to make on your own, and it's not a goal of Baseline to tell you what decisions to make when it comes to adopting new web features, but more a matter of how.