JavaScript Minifier
Safely minify JavaScript โ comments and whitespace out, nothing rewritten.
About this minifier
The provably safe passes: comments stripped by a real tokenizer (so // inside strings and regexes is untouched), indentation removed, blank lines dropped โ and newlines KEPT, because removing them without a full parser gambles with automatic semicolon insertion. Typical savings: 20โ40%.
Why this minifier deliberately does less
JavaScript minification has a danger gradient. Removing comments and indentation is provably safe โ IF the remover can tell a comment from a // inside a string or a regex literal, which is why this tool tokenizes rather than regexes (the difference between "https://example.com" surviving and being amputated at the //). Removing NEWLINES is where amateur minifiers break code: JavaScript's automatic semicolon insertion means two statements joined without their line break can silently change meaning โ the classic return\n value bug โ and doing it safely requires an actual parser. Renaming variables, the biggest win, requires full scope analysis. So the honest ladder: this tool takes the safe rungs (20โ40% smaller, zero risk); build-time minifiers like Terser and esbuild take them all (50โ70%, right for production pipelines); and server gzip โ which you should have anyway โ compresses more than either and stacks with both. Use this for pasted snippets, userscripts, bookmarklets and inline code where a build step is absurd. The CSS minifier applies the same philosophy to stylesheets; the HTML formatter minifies markup.
Frequently asked questions
Why does it keep newlines?
Automatic semicolon insertion: joining lines without parsing can silently change program meaning (the classic return-on-its-own-line bug). A minifier that risks your code's correctness isn't worth 15% โ build tools with real parsers handle that rung.
How is this safe with URLs and regexes?
A real tokenizer tracks strings, template literals and regex literals, so the // in "https://โฆ" or /a\/b/ is data, not a comment. Regex-based comment strippers get exactly this wrong.
How much does it save?
20โ40% typically โ comments and indentation are most of a readable file's fat. Terser-class tools reach 50โ70% by renaming; gzip on the server beats both and stacks with either.
When should I use a real build minifier instead?
For production bundles, always โ Terser/esbuild parse, rename and tree-shake. This tool is for the no-build-step cases: snippets, userscripts, bookmarklets, CMS-pasted code.