Written by Alex Chen · Reviewed by Jane Smith · August 2, 2026
Reduce JavaScript file size by removing comments, whitespace, and unnecessary characters. See exactly how many bytes you save.
Every comment, indent, and blank line you leave in a script is a few bytes the browser still has to download before it can run anything. This page takes a block of JavaScript from the left textarea, removes whatever you authorize with the two checkboxes, and reports exactly how many bytes that saved. It is aimed at front-end developers shrinking an inline script for a theme or snippet, and at anyone who wants to see, concretely, what comments and formatting actually cost in a real file.
Take this deliberately commented function:
// multiply two numbers
function mul(a, b) {
return a * b;
}
That source weighs 65 bytes. With both boxes checked, the comment line is deleted, each remaining line is trimmed, the blank line disappears, and the survivors are concatenated back to back:
function mul(a, b) {return a * b;}
The output is 34 bytes, so the tool reports 31 bytes saved, which is a 47.7% reduction. Run the same function with only one checkbox on and you can watch each operation's individual contribution to that total.
Remove comments runs two regular expressions: one that deletes everything from a // to the end of its line, and one that deletes /* ... */ blocks. Collapse whitespace splits the text into lines, trims each line's leading and trailing spaces, drops lines that are empty, and joins what remains with no separator at all. The savings line underneath the output counts bytes with the browser's Blob API, so the figures are true UTF-8 sizes, not character counts. Leave both boxes off and the tool still runs — the output will equal the input, and the savings will read 0 bytes.
These two operations are plain text transforms, not a JavaScript parser, and that shows in three situations. First, the comment regex cannot tell a comment from a string: a URL like "https://example.com" contains //, which the stripper treats as the start of a comment and deletes everything after it on that line. Second, collapsing whitespace removes newlines entirely, and JavaScript sometimes needs those newlines — return followed by a value on the next line becomes return42, and any statement that relies on automatic semicolon insertion gets fused to its neighbor. Third, a multi-line template literal loses its embedded line breaks, changing the string's content. In every one of these cases the page produces output that looks minified but is not the same program. Nothing here renames variables, removes dead code, or performs any real optimization, so production bundles still belong to a proper minifier such as Terser or esbuild.
Only when the input is semicolon-terminated, keeps each statement on its own line, contains no // inside string literals, and uses no multi-line template strings. If your code meets those conditions, removing comments and indentation cannot change what it does. Otherwise, compare the output against the source before trusting it.
Because semicolon-less JavaScript relies on the line break as its statement separator, and whitespace collapsing joins lines with nothing between them. var a = 1 directly above var b = 2 becomes var a = 1var b = 2, which no longer parses. Add the semicolons first, then minify.
No. The comment stripper treats the // in https:// as the beginning of a comment and deletes the rest of the line, so a string like "https://x.com" comes out truncated. Keep code containing URLs out of the comment-removal path.
It cannot. Shortening names requires parsing the program so every reference is renamed consistently, and this tool does not parse — it only strips. For name mangling and dead-code elimination, pipe the output into Terser or your bundler's minifier.
UTF-8 bytes, computed with the browser's Blob size — the same unit a server uses to bill bandwidth. Non-ASCII characters weigh more than one byte each: a heart emoji alone counts as four bytes, so a script full of emoji in strings will show savings that look small even after heavy trimming.
No. Both transforms are idempotent: the second pass finds no comments left to strip and no newline-separated whitespace left to collapse, so the output and the savings line come back identical. Toggling a checkbox off and on is the only way to change the numbers, and the byte counter recalculates on every run.
Use this page for the small stuff: an inline script in a CMS theme, a bookmarklet, a snippet you paste into a template — places where installing a build chain is overkill and the whole script fits in a textarea. Skip it for anything semicolon-less, anything with URLs in strings, and anything you cannot re-verify after minification. For a real application bundle, let your build tool run Terser with source maps; a stripper like this is not a substitute. And before you run it on code you care about, copy the original somewhere — the page cannot un-minify, and a broken transform of unrecoverable source is a bad trade for a few dozen bytes.