babel.config.js Generator
A Babel configuration for modern JavaScript and TypeScript.
-
1Enter data
Enter content, paste text or load a file from disk. -
2Click the button
The tool will immediately process your data in the browser. -
3Get the result
Copy the finished text or save the file to your device.
return "Result ready in 0.1s";
}
A list of target environments, for example “> 0.5%, last 2 versions, not dead” or “defaults”.
Rate this tool:
Related tools
Other tools you may find usefulbabel.config.js generator - a transpilation setup matched to your browsers
The babel.config.js generator assembles a Babel configuration file from the presets you actually need. Type a list of target environments, decide whether the project uses React and TypeScript, and whether it should handle class fields - the result is a ready module.exports with a presets array and a plugins section. Instead of retyping the syntax from memory you get a file that drops straight into the project root.
How Babel differs from just running the code
Babel is a compiler that turns modern JavaScript - ES2015 syntax and newer, JSX, type annotations - into a form the target environment can run. On its own it does not know what to transform: the configuration tells it. Without a settings file Babel passes code through almost untouched, so babel.config.js is where you declare presets and plugins. A preset is a named bundle of transforms; a plugin is a single transform. The same logic drives the other build files - you assemble the repository ignore list in the gitignore generator before the compiler configuration even comes up.
What this tool produces
The output has a fixed shape: presets ordered the way Babel runs them, and plugins with an optional class-fields plugin. The switches add presets, and duplicates are removed.
| Item | When it enters the file | What it does |
|---|---|---|
@babel/preset-env | always | brings ES2015+ syntax down to the level in the targets field |
@babel/preset-react | when you tick React | processes JSX; runtime: 'automatic' removes the React import from every file |
@babel/preset-typescript | when you tick TypeScript | strips type annotations without checking them |
plugin-proposal-class-properties | when you tick class-properties | handles class fields in loose mode |
babel.config.js versus .babelrc
Babel reads configuration from two kinds of file, and the difference is practical rather than cosmetic. babel.config.js is a project-wide configuration: it applies across the whole tree, including code inside node_modules, which matters when a dependency ships untranspiled sources. .babelrc (or .babelrc.json) is file-relative - it works only in its own directory and subdirectories, and Babel stops looking once it meets a package.json. For monorepos and most new projects the project-wide file is recommended, because a single place describes the whole compilation. This tool generates exactly that babel.config.js. You keep the sibling build files next to it in the same root - the webpack configuration or the tsconfig.json file.
Targets, browserslist and output size
The targets field is the heart of preset-env. It decides how many transforms are applied: the newer the environments you name, the less Babel has to rewrite and the smaller and faster the result. You write the value in browserslist syntax - the same one Autoprefixer and other tools use - so a single value steers the whole build chain. A few common values:
defaults > 0.5%, last 2 versions, not dead last 2 Chrome versions node 18
Rather than repeat the list in each tool, it is worth moving it to a browserslist field in package.json or a .browserslistrc file - then preset-env reads it from there and the Babel config stays short. Naming just node 18 tells Babel the code targets a server, not a browser, so most browser transforms disappear.
Polyfills, @babel/runtime and the syntax boundary
Babel transforms syntax by default, not APIs. An arrow function and a class get rewritten, but Promise, Array.prototype.includes or fetch are runtime features - if the environment lacks them, transpilation alone does not help. Missing APIs are supplied by polyfills (once through @babel/polyfill, today through core-js with the useBuiltIns option in preset-env). Duplication is a separate problem: plugins inject the same helper code into every file. The @babel/runtime package together with @babel/plugin-transform-runtime turns those repeats into one shared import - a noticeable saving in a library you publish for others.
How to use the generator
- Type
targets- this list decides how many transformspreset-envapplies. - Tick React if the project uses JSX; the preset gets
runtime: 'automatic'. - Tick TypeScript if you write in
.ts/.tsx- remember Babel does not check the types. - Leave or clear the class-fields plugin depending on whether you need it.
- Click Generate config, save the result as
babel.config.jsin the project root, then install the listed presets with your package manager.
Frequently asked questions
Does Babel check TypeScript types?
No. @babel/preset-typescript only strips type annotations file by file so that valid JavaScript remains. Type checking stays with the TypeScript compiler (tsc --noEmit) or the editor. This split is deliberate: Babel is fast because it never analyses types across files.
Why runtime: 'automatic' in preset-react?
In automatic mode Babel inserts the JSX helper import itself, so import React from 'react' at the top of every component is no longer needed. The code is shorter and the build raises no unused-import warnings. Classic mode is left only for older React versions.
How does babel.config.js differ from .babelrc?
babel.config.js applies to the whole project, including code in node_modules, and is looked up in the project root. .babelrc applies only within its own directory and subdirectories. For new projects and monorepos the project-wide file is recommended, because a single place describes the whole compilation.
Do I still need Babel with Vite or esbuild?
Usually not for transpilation itself - Vite relies on esbuild, which handles TypeScript and JSX on its own. Babel earns its place when you need a specific plugin (for decorators or a styling library, say) that esbuild lacks, or when you target unusually old browsers. Then the config from this generator plugs into a Babel step alongside the main bundler.