What minifying removes
JavaScript minification removes the parts the engine ignores — line comments (//…), block comments (/*…*/), indentation and surplus blank lines — leaving a compact file that runs byte-for-byte the same. Smaller scripts download and parse faster.
This minifier is a fast, dependency-free whitespace compressor: it strips comments and collapses runs of whitespace while protecting strings, template literals and regular expressions, so text inside quotes is never altered.
Worked example
A commented helper collapses neatly:
function add(a, b) { /* sum */ return a + b; } with comments and indentation.function add(a,b){return a+b;}Limits and safety
This is a lightweight whitespace-and-comment minifier, not a full mangler — it does not rename variables or remove dead code the way build tools such as Terser do, so it is safe to run without a parser and won't break valid code. It keeps newlines where removing them could change meaning (after return, break, etc.) so automatic semicolon insertion still works. For production builds, a bundler will squeeze out more. Everything runs locally — your code never leaves the browser.
Minify, mangle, tree-shake — three different things
"Minify" is often used loosely for everything a build tool does to shrink JavaScript. They're actually distinct steps with very different savings and risks:
| Step | What it does | Needs a parser? |
|---|---|---|
| Whitespace + comment removal | Strips formatting the engine ignores (what this tool does) | No — safe with careful string handling |
| Mangling | Renames local variables userAccount → a, b… without changing behaviour | Yes — must track scopes so it never renames a global or property by mistake |
| Dead-code elimination / tree-shaking | Removes unused functions and unreachable branches, and drops unimported exports across modules | Yes — requires understanding the whole dependency graph |
Tools like Terser and esbuild do all three and can shrink a large bundle far beyond whitespace removal alone. The cost is that they parse and rewrite your code, so they belong in a build pipeline you can test — not pasted blind into a web page.
Why this tool keeps some newlines (and you should care)
JavaScript has automatic semicolon insertion (ASI): in certain places the parser inserts a semicolon at a line break. The most famous trap is return:
return
{ ok: true }; — ASI inserts a semicolon after return, so the function returns undefined and the object is dead code.A naive minifier that collapsed every newline could change meaning here. This tool deliberately preserves newlines after keywords like return, break, continue and throw, so ASI behaves the same before and after. It's also why writing return { on one line (the K&R brace style) is safer than putting the brace on the next line.
A note on source maps and debugging
Once code is minified, a stack trace points at main.min.js:1:48213 — useless on its own. Production build tools emit a source map alongside the minified file so the browser's dev tools (and error-tracking services) can show you the original line. This paste-in tool doesn't generate source maps, which is another reason to reserve it for quick local checks and one-off scripts, and to let your bundler handle anything that ships to users.