What is Google’s Baseline? Should I use it?

by Rob O'Leary on 05 Apr 2025

Google has been working on Baseline for some time now. It is a simplified view of browser support for web features. The primary objective is to make it easier to decide which web features to use.

On paper, it looks like a simple signal that you can follow without any qualms. In reality, there is a possibility that it is an oversimplification and can be misleading. Let’s explore Baseline to see how we can use it.

How is it recommended to use Baseline?

Google’s overview outlines how to use Baseline:

When reading an article, or choosing a library for your project, if the features used are all part of Baseline, you can trust the level of browser compatibility. By aligning with Baseline, there should be no surprises when testing your site.

Jeremy Wagner of Google says the following on usage of Baseline on his discussion about polyfills:

The role of Baseline is to inform you of which features are supported in all major browser engines. You’ll still need to know how many of your users can use Baseline features, and make decisions based on your users and the needs of your project. Baseline Widely available is a good default, and will often have the broadest web feature support for users in many cases.

What does baseline tell us exactly?

Baseline is concerned with a web feature being available in core browsers. The core browser set is:

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

Baseline tell us the following about a web feature:

1. If it is available in every core browser.
2. Approximately how recently the feature has been available in core browsers. It categorised as one of:
   • “newly available” if it has been available in the core browser set for at least two major versions; or
   • “widely available” if it has 30 months since it reached the newly available status.

There was a redefinition of Baseline to include the “widely available” status. The cutoff of 30 months for “widely available” was chosen as it was found that most features take no more than 30 months to be available to about 95% of users globally. It is like a rule of thumb. The thinking is that the web feature can be safely used on most websites after this point.

The concept of interoperability is used loosely when discussing Baseline. Generally, Google appears to deem a web feature being interoperable when it is available in the core set of browsers. Sometimes, it used to denote that the behaviour of a web feature is consistent across all browsers. This fuzzy usage of the term complicates discussions.

What does baseline not tell us?

Baseline does not tell us the following about a web feature that may influence your decision on using it:

1. If a feature has major bugs and is worth avoiding for particular use cases.
2. If a feature has inconsistent implementations across browsers that cause can issues.
3. Which specification it implements, and if fully implements the specification.
4. If a feature can be used as a progressive enhancement.
5. If a feature has a polyfill and could be used across the core browsers with its inclusion. Google explains their thinking on excluding this information from Baseline.
6. Your user’s needs and which browsers they use.

What is the state of a typical web feature that is “newly baseline”?

I was looking at text-wrap: balance in my recent article on CSS resets. Let’s take it as an example to explore how we can view a feature that has made it into Baseline recently.

This feature is categorised by Baseline as “newly baseline” since 2024-05-13. It’s been nearly 11 months now.

This feature was part of Interop 2024. Interop 2024 is defined as a “cross-browser effort to improve the interoperability of the web — to reach a state where each technology works exactly the same in every browser”. It should be in great shape.

If you look at the dashboard for InterOp 2024, which is based on the Web Platform Test suite (WPT), it shows scores of 100% across the board for the 4 core browsers.

Can we conclude that text-wrap: balance works consistently across the browsers then?

If you look up this feature on Web Platform Status, its shows its current WPT scores. They differ from the Interop 2024 dashboard. As of 2025-04-05, the WPT scores are as follows:

• Chrome/Edge: 81.8%
• Firefox: 95.5%
• Safari: 77.3%

That’s strange! If you look at the implementation progress chart further down the page, you can see that more tests were added over the last year.

Actually, the specification for this feature changed last year. The CSS Text Module Level 4 specification was in working draft status, and in February 2024, it made the following changes related to text-wrap: balance:

• Loosened requirement about not changing lines for text-wrap-style: balance for cases with large numbers of lines.
• Define interaction between text-wrap-style: balance and line-clamp .

It appears that this feature is not completely implemented in accordance with the specification yet.

If you look at the bug trackers for the browsers, there are open bugs for text-wrap: balance also:

• text-wrap-style: balance should be allowed to affect the block height (Firefox)
• Setting text-wrap: balance to a parent doesn’t affect its children with display inline-block (Firefox)

The takeaway is that the state of a web feature can fluctuate over time. Even when a feature appears to be completed, the standards can change and codebases can have regressions. Will all of the browser vendors return to iron out the leftover bits soon? 🤷

What is the state of a “widely available” web feature?

I would say generally that features that were deemed important and have been around for a few years are in good shape. It does not rule out inconsistenties between browsers and bugs though.

However, some “widely available” web feature are not in good shape. One example is the details element, which is used to create expandable sections.

It is a focus item in InterOp 2025. This seems like a contradiction? Why is an interoperable web feature (one that is in all browsers for a long time) included in the InterOp initiative?

Well, details has usability issues and limitations. If you don’t know about these, you may happen upon some unwelcome surprises!

Is Baseline support accurately communicated?

There is an official <baseline-status> web component that is used to communicate the baseline information for a web feature. It is used on Google’s web.dev blog and they encourage devs to use it.

It summarises the status as one of: limited availability, newly baseline, or widely available. It shows the four core browsers as icons with a green tick next to it to indicate if it is implemented in that browser(s). It covers the basics as you’d expect.

However, there are some data concerns that can led to unexpected results:

1. It does not consider mobile browsers separately in its presentation. It is possible for a feature to work on Chrome desktop but not in Chrome on Android. This means that occasionally you can get a false positive that is misleading. You can read this GitHub issue for more info. Below is a screenshot of the paint-order property suffering from
   this issue.
2. It uses a new dataset called web-features. It is a big undertaking to create a data model of web features and inevitably there will be errors along the way. It will take time for it to mature. It is reported as having reached 90% coverage of the BCD dataset used by Mozilla Developer Network, which sounds promising. Really though it is hard to tell what state the data is in. The data collection, transformation, and maintenance processes are not documented adequately to gather this.

It has the following usability issues:

1. It is 64KB of minified code. This is a lot for a simple component. It embeds the Lit library and includes unoptimized SVG images for the browser logos.
2. A standalone web component would make it simpler to drop into any website and avoid any side effects. Having Lit as a dependency is avoidable.
3. It has a Learn more link that directs users to the raw source data, which is a YAML file on GitHub. It does not give very useful additional info!
4. The Feature IDs need to be fished from the webstatus.dev website. You need to search for the feature and pluck the ID from the end of the URL. This experience could be improved.

What about supporting information?

The web component is an expandable section, expanding it reveals a Learn more link. Clicking the link directs you to a YAML file for that feature in the GitHub repository for the web-features project, as per screenshot below. It is probably only the description and spec fields that are providing something useful to an user. However it is not in an user-friendly format, you cannot click on the link of the spec field.

Generally, giving more context would help users be more circumspect. Perhaps you could include “known issues” just like can i use does. You could include the Web Platform Test suite summary the same as Web Platform Status. You could include the status of the specification and outline if the feature is fully implemented according to it. You could include if the feature can be employed as a progressive enhancement.

I would not use the web component in its current form. It needs work.

How should Baseline be used?

Baseline can be used to quickly understand the breadth of browser support. I would treat the “widely available” status as a sign of the maturity of a web feature. I would not use Baseline as the arbiter for the usage of a web feature in production. I disagree with the assessment that “by aligning with Baseline, there should be no surprises when testing your site”.

I would include an important caveat. It is important to understand that Baseline does not imply that a web feature works the same across all of the core browsers. We should delineate clearly the difference between a feature being available in all of the core browsers and a feature working the same way across all of the core browsers. Baseline would benefit from clearer messaging in this regard.

Final thoughts

I think Baseline is too short-sighted in its assessment of web features to be used for deciding which web features to use in production. It does not communicate anything on the usability of a feature or the consistency of the implementations across those browsers.

The key fact is that the web is messy – what we call the web platform is multiple codebases trying to do the same thing based on evolving standards, backed by organisations with different priorties and incentives. Understanding which web features to use is more nuanced than simply saying, “it’s in all of the important browsers for a while now, go use it”. Things should be framed better than that.

I’d suggest using Baseline as a rule of thumb at most. You will need to look beyond it for choosing which features to use in production.