What Is a Browser Target? The Browsers You Support
A browser target is the set of browsers and versions your app commits to supporting, which the build uses to decide how to transform code.
Supporting every browser ever made would bloat your output; supporting only the newest would break some users. A browser target draws that line explicitly. The build reads it to decide which syntax to down-level, which polyfills to add, and which CSS prefixes to emit. It is the single configuration that ties together transpiling, polyfilling, and autoprefixing.
How a target is expressed
Targets are usually written as queries like the last two versions of each browser or browsers with more than a small market share. Tools resolve those queries against current browser usage data into a concrete list.
What the target drives
- How much syntax the transpiler down-levels.
- Which polyfills get injected.
- Which vendor prefixes Autoprefixer adds.
The support-versus-size trade-off
A broader target supports more users but ships more transpiled code and polyfills, making the bundle larger and slower. A narrower target ships leaner output but drops some users. The target is a product decision encoded in config.
Shared across tools
Because transpilers, polyfill tools, and PostCSS all read the same browser target, defining it once keeps JS and CSS output consistent. Changing it in one place updates the whole build.
Browser targets in CI/CD
The target affects output, so it must be in committed config and not implicit. CI also depends on the browser usage dataset that resolves the queries; pinning that dataset version keeps builds reproducible, since an updated dataset can otherwise change output without any code change.
Key takeaways
- A browser target is the explicit set of browsers your build supports.
- It drives transpiling, polyfilling, and CSS prefixing from one place.
- CI must pin both the target and the browser dataset version for reproducibility.