What reads the Browserslist config?

Babel preset-env, Autoprefixer, PostCSS plugins, and bundlers like webpack and Vite all share this config to decide which transforms and prefixes to apply, so one query controls your whole toolchain.

What does not dead mean?

The dead query matches browsers without official support and under two percent global usage. Combining it with not, as in not dead, excludes those abandoned browsers from your target set.

How does last 2 versions work?

It selects the two most recent major versions of each browser Browserslist tracks. Pairing it with a usage threshold prevents niche browsers with tiny share from inflating your output.

Should I support Internet Explorer?

Most projects no longer do, since IE reached end of life. Leaving the IE exclusion on keeps your bundles smaller, but you can add a query for it if a legacy audience still requires it.

rc file or package.json field?

Both work identically. A .browserslistrc file keeps the query out of package.json and supports environment sections, while the package.json field keeps everything in one place for small projects.

What is the .browserslistrc Builder?

Takes a global usage threshold, a last-N-versions count, and exclusion rules, then outputs a .browserslistrc file or a package.json browserslist field that Babel, Autoprefixer, and bundlers read to decide their targets. It runs free in your browser on Gera Tools, with nothing uploaded.

.browserslistrc Builder

Name: .browserslistrc Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Control your build targets with one query

Browserslist is the shared source of truth that Babel, Autoprefixer, PostCSS plugins, and bundlers like webpack and Vite consult to decide which browsers to transpile and prefix for. Get it wrong and you either ship bloated polyfills for browsers nobody uses, or you drop real-world users by targeting too narrowly. This builder turns a few choices into a precise, ready-to-use query.

What Browserslist actually does

Every modern JavaScript and CSS build tool has to decide: which features can I assume the browser supports natively, and which need to be transpiled or prefixed? Browserslist answers that question by resolving your queries against the Can I Use usage dataset and returning a concrete list of browser-version combinations.

The resolved list drives:

Babel (@babel/preset-env) — which JS transforms and polyfills to inject
Autoprefixer / PostCSS — which CSS vendor prefixes to add
webpack / Vite / Rollup — which syntax can be left as-is vs compiled
ESLint-plugin-compat — which APIs to flag as unsupported

A single .browserslistrc or browserslist key in package.json configures all of these simultaneously.

How the queries combine

Browserslist treats multiple queries as a union: any browser matching at least one query is included. Within that union, negative queries (prefixed with not) subtract matching browsers. The output is the set of all matching browser-version pairs.

Common query types:

Query	Meaning
`last 2 versions`	Two most recent versions of every tracked browser
`> 0.5%`	Browsers with more than 0.5% global usage share
`not dead`	Exclude browsers with no official support and under 2% usage
`not ie 11`	Explicitly exclude Internet Explorer 11
`defaults`	Shorthand for `> 0.5%, last 2 versions, not dead`

Choosing the right threshold

The usage percentage threshold is the most important variable. Set it too low (e.g. > 0.01%) and you include legacy browsers that add substantial polyfill weight for a fraction of a percent of users. Set it too high (e.g. > 5%) and you drop browsers that still represent millions of real users in your target regions.

A threshold of > 0.5% is a sensible default for most production apps targeting a global audience. If your analytics show a significant portion of traffic from a specific region with an older browser market (for example, older Chrome versions on Android in South or Southeast Asia), consider lowering the threshold or explicitly adding those browsers.

The difference between `.browserslistrc` and `package.json`

Both are equivalent in function. .browserslistrc is a plain-text file that supports multiple environment sections ([production], [development]) so you can use a wider target in development (for debugging purposes) and a narrower one in production. The package.json field works the same way without environment sections unless you use the object form.

Worked examples

Standard production site:

> 0.5%
last 2 versions
not dead
not ie 11

Modern-only SaaS application (tighter bundle):

last 2 Chrome versions
last 2 Firefox versions
last 2 Safari versions
last 2 Edge versions
not dead
> 1%

Legacy support requirement (older enterprise audience):

> 0.2%
last 3 versions
not dead
ie 11

Place the result in a .browserslistrc file at the project root, or paste it into the browserslist array in package.json. Run npx browserslist in your project directory to see the resolved list of browser-version pairs the queries produce.