The September 2025 release of Browserslist 4.26.0 quietly shipped one of the most important updates to the frontend tooling ecosystem in years: first‑class Baseline queries. Instead of juggling hard‑coded browser versions or gnarly percentage rules, you can now write configs like baseline widely available or baseline 2024 and let Browserslist resolve them into concrete targets using MDN’s Baseline data. For teams already investing in modern builds, this change can drastically simplify configuration while aligning your output with a shared, standards‑based definition of “safe” platform features.
Because Browserslist underpins popular tools such as Babel, Autoprefixer, PostCSS, and many bundlers, this single feature unlocks Baseline‑driven targeting across a huge slice of the web by updating just one config. At the same time, the Browserslist team has kept Baseline strictly opt‑in, so existing projects behave exactly as before until you choose to adopt it. In this article, we’ll explore what Baseline is, how Browserslist’s new queries work, and practical ways you can start using them today, without surprising your users or your CI.
Understanding Baseline and why it matters
Baseline is an initiative led by MDN and the WebDX community to answer a deceptively simple question: which web features can developers rely on today across the major browsers? Rather than focusing on individual engine versions, Baseline groups features into two main buckets based on interoperability history: Widely available and Newly available. Features that don’t yet meet this bar are considered of limited availability and aren’t part of Baseline at all.
Under the hood, Baseline draws on @mdn/browser-compat-data and the WebDX web-features dataset, plus mapping layers such as baseline-browser-mapping. These data sources encode when a feature shipped in Chrome, Edge, Firefox, and Safari, and whether support is interoperable and stable. A feature becomes Baseline Widely available once it has been consistently supported across this core browser set for around 30 months. Until it crosses that time threshold, while still being interoperable, it sits in the Baseline Newly available category.
Crucially, Baseline’s scope is intentionally limited. It only considers recent versions of Safari (macOS and iOS), Chrome (desktop and Android), Edge (desktop), and Firefox (desktop and Android). It does not make promises about older releases, niche browsers, OS webviews, or assistive technologies. Nor does it say anything about accessibility, performance, or security. Baseline is a compatibility summary, nothing more, but that’s exactly the kind of summary Browserslist has been missing.
What’s new in Browserslist 4.26.0
Browserslist 4.26.0 introduces built‑in support for Baseline queries. For the first time, you can describe your targets in terms of Baseline feature sets instead of raw version ranges or usage percentages. Rather than weaving together rules like last 2 versions, not dead, or > 0.5%, you can say: “target the browsers where Baseline Widely available features work,” and trust Browserslist to expand that into real versions.
This integration essentially bakes the Baseline mapping pipeline directly into Browserslist. The same underlying data that powered the community browserslist-config-baseline package and tools like bl2bl now lives behind a first‑class syntax. That means you don’t need a separate config package just to speak the language of Baseline, your existing .browserslistrc or browserslist field in package.json becomes the central place to opt into these targets.
Importantly, the Browserslist team made Baseline queries opt‑in. Nothing changes for projects that stick with familiar patterns like defaults, > 0.5%, or explicit version ranges. Only when you add a Baseline query does Browserslist fetch and apply Baseline data. This conservative approach avoids breaking builds while still making Baseline available to any project ready to adopt it.
The three core Baseline query types
Browserslist 4.26.0 supports three primary Baseline query families that map directly onto MDN’s Baseline definitions. First, baseline widely available targets features that have been interoperable across all Baseline core browsers for at least about 30 months. This is the “safe bet” profile: if you want to lean on stable platform capabilities with minimal risk of surprises in modern environments, this is the query to start from.
Second, baseline newly available focuses on features that are interoperable in current versions of the core browsers but haven’t yet reached the 30‑month mark. This gives you a way to aim at the cutting edge of broadly shipped capabilities without dipping into partially supported or experimental territory. However, the Browserslist demo site explicitly cautions that this profile may be aggressive for legacy audiences, because it naturally correlates with newer browser releases and can exclude older, but still common, versions.
Finally, there are year‑based Baseline queries such as baseline 2015, baseline 2020, or baseline 2024. These queries represent the features that were Baseline Newly available at the end of the specified year. In practice, they function like a coarse time‑boxed cap on modern features: you can target a “2020‑era” web platform or a “2024‑era” one, even if you’re building in 2027. Browserslist supports year values from 2015 through the current year, so you can tune your targets to the age of your ecosystem or hardware fleet.
Going beyond the basics: dates and downstream browsers
Baseline data evolves over time as more features become interoperable and cross the 30‑month threshold. Sometimes, though, you need builds that are reproducible against a snapshot of that evolving data. To support this, Browserslist lets you pin Baseline queries to a specific date using the on <YYYY-MM-DD> syntax. For example, you can ask for baseline widely available on 2024-06-06 to obtain the exact browser versions that matched Baseline Widely available on that day.
This kind of date‑pinning is particularly useful for regulated environments, long‑lived LTS branches, and educational material. A tutorial or course can specify its Baseline query and date, ensuring that example builds remain stable even as Baseline definitions change underneath. Teams running reproducible builds across large organizations can similarly lock in a date to avoid “invisible” drift caused by updated MDN data.
The new queries also support a with downstream suffix, which extends the scope beyond the four core Baseline browsers to include downstream Chromium‑ or Gecko‑based browsers. For instance, baseline widely available with downstream instructs Browserslist to factor in related browsers such as Samsung Internet, Opera, or KaiOS where they share engine versions with Chrome or Firefox. You can get even more specific, e.g. baseline widely available with downstream including kaios, to ensure you’re not overlooking important audiences built on the same engines.
From third‑party configs to first‑class support
Prior to 4.26.0, Baseline‑aware Browserslist configurations depended on the community‑maintained browserslist-config-baseline package. That package, developed under the WebDX umbrella, used MDN browser‑compat‑data and Baseline mapping logic to translate Baseline levels into concrete Browserslist queries. It worked well, but required an extra dependency and some non‑obvious setup steps, and it wasn’t automatically visible to every project.
With Baseline queries now built into Browserslist itself, most setups no longer need browserslist-config-baseline at all. You can simply install the latest Browserslist version as part of your regular toolchain updates and start writing Baseline queries directly. The old package is still available and may remain useful for specialized workflows, but for the vast majority of projects, first‑class support is the simpler and more future‑proof option.
The broader Baseline ecosystem also includes tools like bl2bl, a CLI that helps migrate existing configs toward Baseline‑driven ones. It reads your current targets, perhaps a jungle of percentage thresholds and browser exceptions, and proposes equivalent Baseline‑centric configurations, usually based on Baseline Widely available. Under the hood it relies on the same MDN and WebDX data pipeline and encourages frequent updates so your targets keep pace with the evolving platform.
Trying Baseline queries in the Browserslist UI
While you can experiment with Baseline queries locally, the official Browserslist demo site, browsersl.ist, now includes a “Select browser by Baseline” helper that makes exploration much easier. You can type queries like baseline widely available, baseline newly available, baseline 2024, or date‑pinned variants such as baseline widely available on 2024-06-06 and instantly see which browsers and versions match.
The UI also supports advanced forms that showcase the with downstream option. For example, you can try baseline widely available with downstream including kaios and watch the list expand to capture compatible downstream browsers. This gives teams a concrete view of who they’re targeting before changing any project configuration, which can be invaluable when justifying decisions to stakeholders or product owners.
Just as importantly, the site includes documentation snippets and warnings. For instance, when you experiment with baseline newly available, the UI points out that this target leans heavily on very recent versions of the core browsers and may drop support for older but still‑popular releases. This makes the trade‑offs much more tangible than a simple percentage‑based rule, because you’re seeing exact versions rather than abstract numbers.
How Baseline queries flow through your tooling
Browserslist typically sits underneath multiple layers of your stack. Babel uses it to decide which syntax to transpile. PostCSS and Autoprefixer rely on it to determine which CSS features and vendor prefixes are necessary. Bundlers such as Webpack or Vite may pass Browserslist targets to underlying transforms to optimize output for the selected browsers. When you switch to Baseline queries, all of these integrations inherit the new targeting semantics without needing any additional plugins.
This is one reason the Baseline digest for September 2025 calls Browserslist integration a “major tooling integration.” Almost any project already using modern tooling suddenly gains access to Baseline‑aligned targeting by changing a single configuration entry. You don’t need a dedicated “Baseline plugin” for each tool; you just define baseline widely available (or similar) in your Browserslist config and let the ecosystem handle the rest.
Of course, this also means that you should treat Baseline queries with the same care you would any other major change to your browser support matrix. A seemingly simple shift from > 0.5% to baseline newly available can have significant consequences for which polyfills are included, which syntax is transpiled, and which CSS features are considered safe. Before committing to a new query, run test builds, verify bundle behavior in your key browsers, and validate the impact against real analytics data.
Choosing the right Baseline profile for your project
For many production web apps with a broad user base, baseline widely available is the most natural starting point. It represents a consensus on features that have been interoperable for at least 30 months, which usually aligns with what product teams think of as “reasonably modern” browsers. Combined with a few explicit overrides for specific legacy requirements, it can greatly simplify configs while still avoiding surprises for most users.
If you’re working on greenfield projects, internal tools, or products targeted at environments that update quickly, like managed corporate fleets or evergreen kiosk browsers, you might consider baseline newly available to access newer platform capabilities. However, the Browserslist UI’s warning is worth repeating: this profile may be too aggressive for consumer‑facing sites with diverse audiences. Always inspect the resolved browser list and compare it against your traffic before making it the default.
Year‑based queries like baseline 2018 or baseline 2022 are particularly useful when you’re constrained by older hardware, OSes, or platform contracts. They let you say “we will not depend on features newer than the end of 2018,” even if you’re shipping builds in 2026. This can be a lifesaver in long‑lived enterprise contexts, education deployments, or public sector projects where upgrade cycles are slow but you still want a principled, future‑aware definition of supported features.
Baseline integration in Browserslist doesn’t magically solve every compatibility problem, but it does represent a meaningful step toward a more shared, data‑driven understanding of what the web platform can do. By aligning your browser targets with Baseline Widely or Newly available features, or with a particular Baseline year, you’re no longer making ad‑hoc guesses about which versions to include. Instead, you’re tying your decisions to MDN‑maintained data and a clear 30‑month interoperability model.
At the same time, Baseline is just one piece of the quality puzzle. It doesn’t cover accessibility, performance, or real‑world usability; it only summarizes compatibility across a defined core browser set. Even with Baseline‑driven Browserslist configs, you still need to test with assistive technologies, measure performance on low‑end devices, and validate behavior in the specific environments your users rely on. Used thoughtfully, though, Browserslist’s new Baseline queries can dramatically reduce the configuration over of targeting modern browsers, and free you up to focus on building better experiences on top of a clearer, more predictable foundation.