This removes comments and unnecessary whitespace, and nothing else. It walks the source tracking strings, template literals, regular expression literals and both comment forms, so a comment is only stripped where it is really a comment — a double slash inside a string or a regular expression is left alone, which is the difference between working code and a broken file.
Newlines are kept, deliberately. JavaScript inserts semicolons at line breaks under certain conditions, so code written without terminating semicolons changes meaning if its newlines are collapsed. Keeping them costs a little size and removes an entire class of failure. Comments beginning with an exclamation mark are preserved, since that is the convention for licence headers.
The ceiling, stated plainly
-
Nothing is renamed:
a real minifier shortens variable names, and that is where most of the saving in a production bundle comes from. Doing it safely needs a full parser and a scope model, and getting it subtly wrong produces a file that fails in production rather than here.
-
No dead code is removed and no expression rewritten:
the output is your code with its comments and indentation gone. Expect a useful reduction rather than the ratio a build tool achieves.
-
For a real build, use a real bundler:
esbuild, terser or SWC do the renaming and the tree-shaking. This is for a snippet, an inline script or a file with no build step.
-
Deliberately conservative on ambiguity:
whether a slash starts a regular expression or divides cannot be decided without parsing. The heuristic here is correct for the forms that occur in practice, and where it is unsure it leaves the code as it is.
What it actually removes: comments and whitespace, nothing more
The [msm_tool slug="js-minifier"] walks the source tracking strings, template literals, regular expression literals and both comment forms, so a double slash sitting inside a string or a regular expression is left alone rather than mistaken for the start of a comment. That distinction is the difference between a working file and one where `"https://example.com"` loses everything after the second slash.
Newlines stay, on purpose
JavaScript inserts semicolons at line breaks under certain conditions, so code written without terminating semicolons changes meaning the moment its newlines are collapsed away. Keeping every line break costs a little size and removes an entire category of failure that a naive whitespace collapse would otherwise introduce.
Licence comments are recognised, not just kept by accident
A comment beginning with an exclamation mark is preserved specifically, since that is the established convention for a licence header. Every other comment is removed, but this one exception exists because stripping a required licence notice is a different kind of mistake from stripping an ordinary code comment.
Where the ambiguous slash is handled conservatively
Whether a slash begins a regular expression or performs division cannot be decided with certainty without actually parsing the surrounding code. The heuristic used here is correct for the forms that show up in practice, and wherever it is genuinely unsure, it leaves the code exactly as written rather than guessing and risking a break.
Nothing is renamed, and that is most of the missing saving
A real production minifier shortens variable and function names, which is where most of the size reduction in a built bundle actually comes from — and doing that safely needs a full parser and a scope model, since getting it subtly wrong produces code that fails only after it ships. This tool does not attempt it, so the reduction here is real but modest: comments and indentation gone, nothing structural changed.
Where a real build tool is the right choice instead
Anything with an actual build step is better served by esbuild, Terser or SWC, which perform the renaming and dead-code elimination this deliberately does not. This is built for the opposite case: a standalone snippet, an inline script, or a file with no build pipeline behind it at all.