JavaScript Minifier

A byte of JavaScript is more expensive than a byte of almost anything else. An image is downloaded and decoded; a script has to be downloaded, parsed, compiled, and executed, and on a mid-range phone that work happens on the same main thread that handles rendering and input. That is why a page can look loaded and still not respond to taps, and why script weight dominates Interaction to Next Paint. Minification helps at the download stage, but parse and execute costs scale with how much code you ship, not how compactly it is written.

Minification is the last and smallest step. The changes that move the needle are structural: code-splitting so a route only loads what it needs, deferring anything not required for the first paint, replacing a large dependency with a smaller one or with platform APIs, and removing packages that are no longer used at all. A bundle analyser is the fastest way to see where the weight is, and the answer is usually one or two dependencies rather than your own code.

Removing comments and whitespace typically takes 20% to 50% off a hand-written file, and the figure under the output is the real measurement for yours. A production bundler goes considerably further, because it also shortens local variable names, removes unreachable code, and drops branches that can never run — which is why a properly built bundle is smaller than anything whitespace removal alone can achieve. Note too that gzip and Brotli already compress repeated whitespace well, so the saving on the wire is smaller than the saving on disk.

For ordinary code, yes: only characters the parser ignores are removed, and the contents of strings, template literals, and regular expressions are preserved exactly. The caveat is that whitespace removal has to respect automatic semicolon insertion, so if your code omits semicolons in unusual places, test the output before shipping. For anything going to production, prefer a real minifier such as terser or esbuild inside your build, because it parses the code properly rather than working on it as text.

It will not produce them. A sourcemap records how each position in the output corresponds to the original source, and it has to be generated by whatever performed the transformation. Minifying here produces code with no map, so browser devtools will show you the compressed file. If you need to debug production issues against original source, minify with a build tool configured to emit sourcemaps instead.

After. A bundler needs to parse your modules to resolve imports, tree-shake unused exports, and decide what belongs in which chunk, and minified input makes all of that harder while gaining nothing — the bundle gets minified at the end anyway. The standard order is bundle, then minify, then compress with gzip or Brotli at the server. Minifying by hand is for standalone scripts that never go through a build at all.

No. Everything runs in your browser as JavaScript — your code is never uploaded, never logged, and never sent to a server. You can verify that by watching the Network tab in devtools while you work, or by disconnecting from the internet after the page loads and confirming the tools still function. Nothing you paste is executed either; it is only ever parsed as text.