JavaScript Minifier

JavaScript minification is the process of removing all unnecessary characters from source code without changing its functionality. Those unnecessary characters include whitespace, newlines, comments, and block delimiters. The result is a smaller file that downloads faster and executes just as correctly as the original.

Every byte you send over the network costs time. On a slow mobile connection, a bloated script can delay the first interactive moment of a page by hundreds of milliseconds. Minification is one of the cheapest performance wins available because it requires zero changes to your logic — it simply strips the fat that humans need (comments, indentation) but browsers do not.

This JavaScript minifier calculator accepts raw JS source, applies a sequence of regular-expression transformations, and shows you the minified output alongside a compression summary. The summary reports the original byte count, the minified byte count, the total bytes saved, and the percentage reduction — so you know at a glance whether minification is worth it for a given file.

Minification is distinct from obfuscation (which renames variables to meaningless identifiers) and from bundling (which merges multiple files into one). All three techniques are often combined in modern build pipelines, but minification alone is what reduces whitespace and comments, and it is always the first step.

The minifier applies a deterministic chain of regular-expression replacements to the input text. Understanding the order matters because each step produces the input for the next one.

1. Strip single-line comments — Any text from // to end of line is removed, using a negative lookbehind to avoid stripping the // inside URLs such as https://.
2. Strip multi-line comments — Everything between /* and */ (including across line breaks) is removed.
3. Trim lines — Leading and trailing whitespace on every line is stripped.
4. Remove empty lines — Lines that contain only whitespace after trimming are deleted.
5. Collapse newlines — All remaining newline characters are removed, merging the code onto a single line.
6. Collapse internal spaces — Multiple consecutive spaces are reduced to a single space.
7. Remove spaces around operators — Spaces adjacent to { } ( ) [ ] ; , = + - * / < > ! & | ? : are removed.
8. Restore keyword spacing — Because step 7 may have removed the required space after keywords like var, let, const, function, return, if, else, for, while, new, and typeof, each keyword is rewritten with a trailing space.

After all replacements, the string is trimmed of any outer whitespace. The result is the minified output displayed in the output panel.

The compression summary then computes:

• Original size: input.length (characters, which equal bytes for ASCII-range JS)
• Minified size: minified.length
• Bytes saved: original.length - minified.length
• Reduction: ((1 - minified.length / original.length) * 100).toFixed(1)

Page speed is a confirmed ranking signal in Google Search. The Core Web Vitals metric Largest Contentful Paint (LCP) is directly affected by how long the browser waits for render-blocking scripts to download and parse. Minifying JavaScript is one of the fastest ways to improve LCP without touching server infrastructure.

Consider a script that starts at 80 KB. A 40% reduction through minification brings it to 48 KB. On a 3G connection at roughly 1 Mbps effective throughput, that difference is about 250 ms of download time — and that is before accounting for parse time, which also scales with file size.

Beyond raw speed, minification matters for:

• Bandwidth costs — Hosting providers and CDNs often charge by data transferred. Smaller files mean lower bills at scale.
• Cache efficiency — A smaller file fits more easily into browser caches and CDN edge caches.
• Mobile users — Mobile CPUs parse JavaScript more slowly than desktop chips. Fewer bytes means faster parse time.
• Lighthouse scores — Google Lighthouse flags unminified JavaScript as an opportunity and estimates the savings, directly affecting your performance score.

Even if you use HTTP/2 or HTTP/3 multiplexing and gzip/Brotli compression, minification still helps: gzip compression ratios improve when the input has already been stripped of redundant whitespace, because the compressor finds repeating patterns more easily in dense code.

These three terms are often confused. They address different problems and operate at different layers of the delivery pipeline.

For production workflows, the recommended stack is: tree-shake first (remove dead code), minify second (remove whitespace), then serve with Brotli compression. Each layer compounds the savings of the previous one. This calculator addresses the minification layer specifically.

This calculator's minifier is a regex-based approach suited for quick estimates and educational use. It handles the most common patterns — stripping comments and collapsing whitespace — but it has known limitations compared to production tools like Terser, esbuild, or SWC.

Limitations of regex-based minification include:

• String literals — A comment-like sequence inside a string (e.g., "// not a comment") may be incorrectly stripped by a naive regex if the lookahead logic is insufficient.
• Automatic Semicolon Insertion (ASI) — Removing all newlines can break code that relies on ASI at the end of a statement.
• Template literals — Backtick strings containing newlines or expressions may be mangled by whitespace-collapse rules.
• No dead-code elimination — Unused variables and unreachable branches are kept as-is.
• No scope-aware renaming — Local variable names remain long; only Terser/UglifyJS rename them to single letters.

Production tools parse the code into an Abstract Syntax Tree (AST) before transforming it. AST-based tools are safe by construction because they understand the language grammar. They also provide additional optimizations: constant folding, inline expansion of short functions, and dead-branch elimination. For any script that ships to real users, use an AST-based tool in your build pipeline (webpack with Terser, Vite/Rollup with esbuild, Next.js built-in SWC minifier, etc.). Use this calculator to estimate potential savings and understand what minification does before setting up a pipeline.

Once you paste JavaScript into the input area, the compression results panel updates in real time. Here is how to interpret each metric:

• Original Size (bytes) — The character count of your raw input. For standard ASCII-range JavaScript, one character equals one byte.
• Minified Size (bytes) — The character count of the processed output.
• Bytes Saved — The difference: originalLength - minifiedLength. This is the amount you shave off every download of this file.
• Reduction (%) — Calculated as ((1 - minifiedLength / originalLength) × 100), rounded to one decimal place. Typical comment-heavy source files see 20–50% reduction; tightly-written utility scripts may see only 5–15%.

A high reduction percentage does not always mean better performance in isolation. A 1 KB file reduced by 50% saves 500 bytes — negligible compared to a 200 KB library reduced by 30% that saves 60 KB. Always consider absolute bytes saved, not just the percentage, when prioritizing minification efforts across a codebase.