Visual Studio Code now supports Baseline  |  Blog  |  web.dev

Published: May 20, 2025

Modern code editors unlock so much productivity by bringing together the tools and reference docs you need to build things efficiently—it’s the I in IDE. One productivity enhancement in many IDEs like Visual Studio Code (VS Code) is showing additional information about web features as you hover over them in the editor. This information helpfully includes a description of the feature, supported browsers, a syntax guide, and a link to learn more on MDN.

Browser compatibility information is especially useful in the context of an IDE, because you can get instant feedback about how interoperable a feature is, just by hovering over it. You could use this information to decide whether a feature meets your browser support targets, whether you need to take defensive steps to progressively enhance or polyfill it, or hold off from using it entirely.

Earlier versions of VS Code expressed this information in terms of browser version numbers, similar to what you might have seen in compatibility tables on sites like MDN, Can I Use, or here on web.dev. But what all of these sites have in common is that they’ve also started summarizing the complex landscape of browser support using Baseline. So, in an effort to align VS Code with the way these other resources convey browser compatibility information, VS Code now supports Baseline as well.

To get the new Baseline UI, upgrade to VS Code version 1.100 or newer. Everything works out of the box—no extensions or extra configuration needed.

When you hover over a web feature in the latest version of VS Code, you’ll see its Baseline status. And to give you a sense for how long the feature has been supported, VS Code will also tell you the year it became Baseline. Or, for features that are not yet Baseline, it’ll tell you in which browsers the feature is not yet fully implemented.

In earlier versions of VS Code, this wasn’t so straightforward. It does take a bit of thought to look at a list of supported browser versions and work out which browsers are missing. Perhaps the least straightforward part to figure out was how long the feature has been supported across browsers. For that, you’d need to know when each version was released, which isn’t exactly common knowledge! Fortunately, all of that is factored into the Baseline status and year.

This release also includes something completely new. Previously, you’d only be able to pull up browser support data for CSS properties. This was especially useful given the incredible pace at which new CSS features are shipping every year. But there’s a lot of innovation happening in HTML as well! As of this release, VS Code will also start showing browser support information for HTML elements and attributes in terms of their Baseline status.

For example, the autocorrect input attribute shipped in its first browser, Firefox, just a couple of months ago. It’s nice to be able to get the immediate feedback that the feature has limited availability, so you can be more informed about where it will or won’t work. In this particular case, it’s harmless in unsupported browsers, so go for it!

Other HTML features like the dialog element don’t degrade as gracefully as autocorrect. So it’s reassuring to be able to invoke the dialog hovercard and see that it has in fact been Baseline since 2022 and is considered Widely available across major browsers. Something like this should give you the confidence to adopt features that you might have otherwise thought were too cutting-edge.

The Popover API is another example of an HTML feature that has also been Baseline, but only since 2024, so it’s still considered Newly available. That means that while it’s supported by all of the major browsers, it hasn’t quite been the 2.5 years required to become Widely available. So you might want to proceed with a bit more caution before shipping this feature to all of your users.

Having this information at the ready in VS Code is a great productivity boost. But what if you didn’t even need to hover over a feature to see if it’s Baseline? That’s made possible by a separate but related tool: linters.

For example, the ESLint extension for VS Code can lint your HTML and CSS files and add squiggly underlines to any features that are not yet Baseline. This is powered by the recently added use-baseline rules from the HTML ESLint and ESLint for CSS plugins. There’s a similar rule for Stylelint as well, if that’s your thing. Of course, this is just one of many benefits of linters, but it goes to show how well they complement the new Baseline-enabled hovercards.

If you’re a VS Code user, I hope you give the new hovercards a try. And if you’re not a VS Code user, I have some very good news. Many IDEs are either forked from Code – OSS (the open source version of VS Code) or rely on the same language servers that power its HTML and CSS hovercards. These downstream IDEs may take weeks or months to upgrade to the latest version, but when they do, they should inherit the new Baseline UI automatically:

• VSCodium
• Firebase Studio
• Cursor
• Windsurf
• Zed
• Eclipse Theia
• Trae
• GitHub codespaces
• GitLab workspaces
• Replit
• StackBlitz (Bolt)

JetBrains is also working to integrate Baseline with all of their IntelliJ-based IDEs, starting with WebStorm. We’ll have more to say about that in a separate blog post—stay tuned.

More and more developer tools and resources are adding Baseline support, and these new IDE integrations led by VS Code are especially exciting. We spend so much time in our IDEs, and having this Baseline data at our fingertips will help bring even more clarity and cross-tooling consistency to our development workflows. To learn more about Baseline and other tooling integrations like this, head over to our Baseline guide for more resources.