JavaScript Minifier
Paste JavaScript and get a compressed version instantly, comments and extra whitespace stripped, strings and template literals left completely untouched.
About the JavaScript Minifier
The minifier reads your code one character at a time, keeping track of whether it's currently sitting inside a single-quoted string, a double-quoted string, a template literal, or a comment, so a // or /* */ pattern buried inside a string is never mistaken for a real comment. Once that's sorted, comments get dropped and stray whitespace collapses down to a single space.
Worth knowing: this stays at the whitespace and comment level rather than parsing a full AST, so it won't rename variables, strip dead code, or reason about regex literals specially. Template strings, interpolations (${...}) included, pass through byte for byte.
An honest gap: no regex-literal awareness, unlike this site's JS Beautifier
The site's JavaScript Beautifier deliberately tracks the preceding token to correctly tell a division slash apart from the start of a regex literal, this minifier doesn't attempt that at all. Since it only recognizes strings, template literals, and comments, a regex pattern that happens to contain // internally, like /https:\/\//, or one written directly with an unescaped double-slash inside its pattern, isn't specially protected the way a string's contents are. In practice, well-formed regex literals almost always escape internal slashes anyway, so this is a narrow edge case rather than a common failure, but it's the real reason these two related tools take deliberately different approaches to the same underlying ambiguity, the beautifier needs to lay out code structurally and must get this right, while the minifier's simpler six-mode design trades that specific correctness for a smaller, easier-to-verify implementation.
Why whitespace collapsing waits until it sees what comes next
Rather than immediately writing a space to the output the instant it encounters one, the minifier sets a pendingSpace flag and defers the actual decision until it reaches the next real character. Only then does it check whether a space is genuinely needed: if the upcoming character is one that never needs a space before it (like ;, }, ), or ,), or if the last character already written never needs a space after it (like { or (), the pending space gets silently dropped instead of inserted. This deferred approach is what keeps output like function foo() { from picking up an unnecessary trailing space before the brace, while still correctly preserving the required space in something like return x, where removing it would merge two words into an entirely different identifier.
Why single and double quotes get separate modes instead of one generic "string" mode
The minifier tracks MODE_SINGLE and MODE_DOUBLE as distinct states rather than one shared "inside a string" mode, because knowing exactly which quote character will end the current string is essential: a single-quoted string like 'it's fine' would be nonsensical as raw JS, but a properly escaped one, or a double-quoted string containing an unescaped apostrophe, needs the scanner to know specifically which quote character to watch for. Tracking them separately means the exit condition for each mode is unambiguous, watch for this exact quote character, rather than needing extra logic to remember which quote type started the current string.
Why escaped characters get copied as a pair, not examined individually
Inside a string or template literal, whenever the scanner encounters a backslash, it immediately copies both the backslash and whatever character follows it together, advancing two positions at once rather than one. This prevents an escaped quote like \" inside a double-quoted string from being misread as the string's actual closing quote, since the character right after the backslash is never independently checked against the "is this the closing quote" condition. Skipping that pair together is what keeps strings containing escaped quotes, backslashes, or other escape sequences intact through the minification process.
Frequently Asked Questions
Can a regex literal with "//" inside it get accidentally treated as a comment?
Potentially, in a narrow edge case. Unlike the site's JS Beautifier, this minifier doesn't specially track regex literals, only strings, template literals, and comments. A regex containing an unescaped internal double-slash isn't protected the way string contents are, though well-formed regex patterns almost always escape internal slashes anyway.
Why does the minifier wait to decide whether to insert a space?
It defers the decision using a pendingSpace flag until it sees the next real character, then checks whether a space is actually needed based on both that upcoming character and the last character already written. This avoids inserting unnecessary spaces before punctuation like ; or } while still preserving spaces that are functionally required, like between return and a following identifier.
Why are single-quoted and double-quoted strings tracked as separate modes?
Because the scanner needs to know exactly which quote character will end the current string. Tracking them as distinct modes makes each one's exit condition unambiguous, rather than needing extra logic to remember which quote type started the string currently being scanned.
How does the minifier avoid ending a string early on an escaped quote?
Whenever it encounters a backslash inside a string, it copies the backslash and the character immediately following it together as a pair, advancing two positions at once. This means the escaped character is never independently checked against the closing-quote condition, so \" inside a double-quoted string doesn't prematurely end it.
Does this minifier rename variables or remove unused code?
No, it operates purely at the whitespace and comment level rather than parsing a full syntax tree. Variable renaming, dead code elimination, and other AST-level optimizations are out of scope, it's a whitespace-and-comment-safe minifier, not a full optimizing compiler.
Is it safe to minify code containing template literals with ${} interpolations?
Yes, template literal content, including everything inside ${ } interpolations, is copied through completely untouched. The minifier only collapses whitespace and strips comments in normal code, never inside a template literal's boundaries.