What your browserslist query is actually targeting

One line in package.json decides which syntax your bundler keeps, which prefixes get added, and which CSS your linter flags. Most projects never look at what it resolves to:

"browserslist": ["defaults"]

You can see the answer for yourself in one command:

npx browserslist "defaults"

The short version: defaults is documented as > 0.5%, last 2 versions, Firefox ESR, not dead, and it pulls in Opera Mini, KaiOS and UC Browser. last 2 versions on its own still pulls in Internet Explorer. And there are now Baseline queries that express "modern browsers" far more honestly than either.

Every resolved list below comes from browserslist 4.29.0 with caniuse-lite 1.0.30001810, on 16 September 2026. These lists change with every data update, which is the whole point of the last section.

What defaults expands to

The README is explicit: defaults means "Browserslist's default browsers (> 0.5%, last 2 versions, Firefox ESR, not dead)". Four queries, unioned.

Resolved today, that is 32 browser versions. The parts people expect:

chrome 151, 150, 149, 148, 145, 120, 109
edge 151, 150, 149
firefox 154, 153, 152, 140
safari 26.6, 26.5     ios_saf 26.6, 26.5, 18.5-18.7

And the parts they do not:

op_mini all, kaios 3.0-3.1, kaios 2.5, and_uc 15.5, and_qq 14.9, op_mob 80

Opera Mini is in there because it clears 0.5% of global usage, and not dead does not remove it — dead is defined as "browsers without official support or updates for 24 months", and the README lists exactly what that currently covers: IE 11, IE_Mob 11, BlackBerry 10 and 7, Samsung 4, Opera Mobile 12.1 and all versions of Baidu. Opera Mini is maintained, so it stays.

That matters because of what Opera Mini supports. In the same caniuse-lite data, op_mini all is recorded as not supporting CSS Grid, custom properties, CSS nesting or :has(). Any tool that asks "is this supported by every browser in the list?" answers no to all four, purely because of one entry you did not know you had asked for. KaiOS 3 is milder — it has grid and custom properties, but not nesting or :has().

Chrome 109 and 120 are in the list for a different reason: > 0.5% is a usage threshold, not a recency one, and those two versions are still that popular globally.

last 2 versions still means Internet Explorer

This is the classic footgun, and it is worth seeing resolved:

and_chr 151, and_ff 153, and_qq 14.9, and_uc 15.5, android 151,
baidu 13.52, bb 10, bb 7, chrome 151, chrome 150, edge 151, edge 150,
firefox 154, firefox 153, ie 11, ie 10, ie_mob 11, ie_mob 10,
ios_saf 26.6, 26.5, kaios 3.0-3.1, kaios 2.5, op_mini all, op_mob 80,
opera 131, opera 127, safari 26.6, 26.5, samsung 30, samsung 29

last 2 versions means the last 2 versions of each browser Can I Use knows about, including ones that stopped shipping years ago. IE 10 and 11, BlackBerry 7, Baidu — all present. Written on its own, this query constrains what you can ship far more than defaults does, not less.

If you want a query of that shape, the README recommends last 2 versions, not dead, > 0.2%, and attaches a caution: leaning only on a usage percentage "will in the long run make popular browsers even more popular. We might run into a monopoly and stagnation situation, as we had with Internet Explorer 6."

The Baseline queries

Browserslist can take its targets from Baseline instead of usage statistics:

baseline widely available resolves to a clean list, and its floor is the useful bit:

chrome 121+   edge 121+   firefox 123+   safari 17.4+   ios_saf 17.4+

That is a real, defensible answer to "what counts as a modern browser" — and unlike defaults, it is derived from feature support rather than from market share. baseline 2023 drops the floor to Chrome 120, Firefox 121 and Safari 17.2, which is how you loosen it by a known amount instead of by guesswork.

Those floors are the useful numbers; the resolved list also carries the "latest version only" entries Can I Use keeps for Chrome and Firefox on Android.

Note what is missing: Samsung Internet, Opera Mobile and the rest. The Baseline core browser set is exactly seven entries — Chrome, Chrome for Android, Edge, Firefox, Firefox for Android, Safari and Safari on iOS. Add with downstream if you need browsers built on Chromium or Gecko to be represented.

If you would rather depend on a package than a query string, the README also points at browserslist-config-baseline.

The 30-month trick behind "newly available"

baseline newly available has no separate implementation. Browserslist computes it as the Widely available set on a date 30 months from today — which is exactly right, because Newly available becomes Widely available after 30 months. You can see the arithmetic in the error you get if you try to combine them: asking for baseline newly available on 2026-01-01 tells you to "use widely available on YYYY-MM-DD and add 30 months to the date you specified".

That implementation detail has a consequence worth knowing about, which is the next section.

When a browser silently vanishes from your query

Resolved today, baseline newly available returns four entries: Safari 26.5, Safari 26.6 and the two matching iOS Safari versions. No Chrome. No Firefox. No Edge.

Nothing is broken. The Baseline mapping says the feature set currently requires Chrome 152, Edge 152 and Firefox 155 — but the installed caniuse-lite only knows about Chrome up to 151 and Firefox up to 154. Versions it has never heard of cannot appear in the output, so those browsers drop out of the list entirely rather than appearing with a high floor.

A query that quietly targets fewer browsers than you think is worse than one that errors. The fix is the one the project already recommends:

npx update-browserslist-db@latest

Run it when you update dependencies, not when something looks wrong. Any query that leans on recent versions — last 2 versions, baseline newly available, cover 99.5% — is only as current as that database.

The US and Brazil are not the same target

Browserslist takes regional usage data with a two-letter country code, and for anyone shipping across the Americas the difference is not academic. The same 0.5% threshold, resolved two ways:

A US-weighted list is held back by old iPhones; a Brazil-weighted one is held back by old Chrome on Android and desktop, and barely registers desktop Safari at all. If your analytics say most of your traffic is in one market, > 0.5% in US or > 0.5% in BR describes it far better than a global threshold — and > 0.5% in my stats, fed from your own analytics export, describes it better still.

What to put in your config

• Most projects: defaults is a reasonable starting point and the maintainers say so. If a tool is refusing modern features on Opera Mini's account, defaults, not op_mini all drops it and leaves the other 31 entries alone.
• A product with real analytics: > 0.5% in my stats, not dead, exported from your own data. Nothing beats your own numbers.
• A design system or library that wants a defensible "modern" line: baseline widely available, optionally with downstream. It is a rule you can explain to a reviewer.
• Anything at all: run npx update-browserslist-db@latest regularly, check the resolved list with npx browserslist before you argue about whether a feature is safe, and run browserslist-lint once — it exists specifically to catch the popular mistakes above.

If the underlying question is "can I ship this feature", the query is only half the answer. The site's guide to whether a CSS feature is safe to ship covers the other half.

Sources

• Browserslist — the query reference, the defaults expansion, the dead definition and the Baseline queries
• update-browserslist-db — the CLI for refreshing the browser database
• web-features — the Baseline dataset the Baseline queries are derived from
• baseline-browser-mapping — how Baseline feature sets map to browser versions, including downstream browsers
• caniuse-lite — the usage and feature-support data every query above is resolved against