JavaScript Minifier

About JavaScript Minifier

How JavaScript Minification Works

A minifier processes your source code in several steps, each targeting a different type of removable content. The key challenge is distinguishing between whitespace that's purely cosmetic and whitespace that's syntactically meaningful.

Step 1 - Extract protected content: The minifier first pulls out string literals (single and double quoted), template literals (backtick strings), and regular expression patterns. These are replaced with temporary placeholders so the following steps don't accidentally modify them. A regex like /hello world/gi contains spaces that must survive intact, and a string like "// not a comment" contains characters that look like a comment start but aren't one.

Step 2 - Strip comments: With strings safely extracted, every // through to end-of-line and every /* ... */ block is removed. In heavily-documented codebases, JSDoc blocks alone can account for 30-40% of total file size.

Step 3 - Collapse whitespace: Indentation (tabs and spaces at the start of lines), blank lines, and trailing whitespace are all removed. Multiple consecutive spaces between tokens collapse to a single space.

Step 4 - Clean operators: Spaces around operators and punctuation are removed where safe. x = a + b; becomes x=a+b;. Trailing semicolons before closing braces are also stripped since JavaScript's grammar doesn't require them in that position.

Step 5 - Restore protected content: The placeholders are swapped back to the original strings, template literals, and regex patterns. The output is syntactically identical to the input - just shorter.

Worked example:

// Original (263 bytes)
function calculateTotal(items) {
  // Sum up the prices
  let total = 0;
  for (const item of items) {
    total += item.price * item.quantity;
  }
  /* Apply discount if eligible */
  if (total > 100) {
    total = total * 0.9;
  }
  return total;
}

// Minified (88 bytes)
function calculateTotal(items){let total=0;for(const item of items){total+=item.price*item.quantity}if(total>100){total=total*0.9}return total}

That's 175 bytes saved - a 67% reduction from a short function. The two comment blocks (31 bytes combined), the blank line, all indentation, and operator spacing are gone. The code runs identically.

What Gets Removed and What's Preserved

Removed	Example
Single-line comments	// calculate total
Multi-line comments	/* helper function */
Blank lines	Empty lines between code blocks
Indentation	Tabs and leading spaces
Trailing whitespace	Spaces at end of lines
Spaces around operators	x = a + b becomes x=a+b
Trailing semicolons before }	return x;} becomes return x}

Preserved	Why
String literals ('...', "...")	Content must remain exact
Template literals (`...`)	May contain expressions and whitespace-sensitive content
Regular expressions (/pattern/)	Slashes and spaces inside regex are syntactically significant
Keyword-separating spaces	"return value" cannot become "returnvalue"

The distinction matters most with regular expressions. A forward slash outside a string could be a division operator or the start of a regex - the minifier uses the preceding character as context to decide which one it is. This is the same ambiguity that trips up syntax highlighters and even some production tools on edge cases.

Typical Savings by Code Type

Code Type	Typical Reduction	Notes
Heavily-commented library code	30-50%	JSDoc blocks and inline explanations add significant bytes
Application code with moderate comments	20-35%	Standard development code with some formatting
Already-compact code	10-15%	Minimal comments, tight formatting
Previously minified code	0-2%	Nothing left to remove

The savings depend almost entirely on how much commenting and formatting the original code contains. A file full of JSDoc annotations will compress dramatically. A terse utility with no comments will barely shrink. The tool displays exact byte counts after each minification so you can see the actual impact immediately.

Why JavaScript File Size Matters

According to the HTTP Archive's 2025 Web Almanac, the median web page loads 697 KB of JavaScript on desktop and around 558 KB on mobile, spread across 22-23 separate files. That's up from 613 KB on desktop in 2024 - an increase of 84 KB in a single year. JavaScript is now the second-heaviest resource type after images, and the most expensive byte-for-byte because the browser must download, parse, compile, and execute it before the page becomes interactive.

Every kilobyte of JavaScript directly affects Core Web Vitals. Total Blocking Time (TBT) measures how long the main thread is locked up by script execution, and Largest Contentful Paint (LCP) can be delayed when render-blocking scripts haven't been deferred. Google uses both metrics as ranking signals, so smaller JavaScript bundles improve both user experience and search visibility.

On a typical 4G mobile connection at around 10 Mbps, 700 KB of JavaScript downloads in about half a second. Drop to a slow 3G connection at 1.6 Mbps and that same payload takes 3.5 seconds before the browser even starts parsing. Basic minification that removes 30% of the weight shaves a full second off that download on slow networks - a difference users notice immediately.

This Tool vs Production Build Tools

Feature	This Tool	Terser / esbuild / SWC
Comment removal	Yes	Yes
Whitespace removal	Yes	Yes
Variable renaming (mangling)	No	Yes - renames variables to shorter names
Dead code elimination	No	Yes - removes unreachable code
Tree shaking	No	Yes - removes unused exports
Constant folding	No	Yes - evaluates constant expressions at build time
Source maps	No	Yes - maps minified code back to source
Setup required	None - paste and click	Node.js, config files, build scripts

The gap between basic and advanced minification is significant. According to the minification-benchmarks project on GitHub (privatenumber/minification-benchmarks), esbuild compresses React's source from 19.5 KB down to 8.4 KB in 3 ms. Terser achieves slightly better compression at 8.26 KB but takes 215 ms. SWC lands at 8.19 KB in 18 ms, balancing compression and speed. All three achieve roughly 58% compression on that benchmark versus the 20-40% you'd get from whitespace and comment removal alone, because they rename variables to single characters, evaluate constant expressions at build time, and strip unreachable code paths.

Use this tool for quick one-off tasks: checking how much a snippet compresses, preparing code for a forum post, stripping comments before sharing, or getting a quick size comparison. For production deployment, integrate Terser, esbuild, or SWC into your build pipeline for the best possible compression.

The Full Size Optimization Pipeline

Stage	Typical Reduction	Cumulative Savings
Basic minification (this tool)	20-40%	20-40%
Advanced minification (Terser/esbuild)	40-60%	40-60%
Gzip compression (server-side)	~65% of minified size	~85% total
Brotli compression (server-side)	~70% of minified size	~90% total

Minification and HTTP compression complement each other. Minification removes human-readable formatting that compressors would partially handle anyway, but the combination is always better than either alone. According to Akamai's compression research, Brotli achieves median savings of 82% across web assets versus 78% for gzip. Brotli's built-in dictionary includes common JavaScript tokens like "function", "return", and "const", which gives it a consistent edge on JS files specifically. Most modern CDNs - including Cloudflare, Fastly, and AWS CloudFront - serve Brotli to supporting browsers automatically and fall back to gzip for older clients.

Code splitting and lazy loading provide additional savings by ensuring users only download the JavaScript they actually need for the current page, rather than the entire application bundle upfront.

Common Minification Pitfalls

A few patterns that catch developers off guard when minifying JavaScript:

• Automatic Semicolon Insertion (ASI): JavaScript automatically inserts semicolons in certain situations, but the rules are subtle. Code like return\n{value: 1} returns undefined, not the object, because ASI inserts a semicolon after return. Minification collapses newlines, which can change ASI behaviour in edge cases. Always use explicit semicolons and keep return values on the same line as the return keyword.
• License comments: Some projects require license headers in distributed files. Basic minification strips all comments indiscriminately. Production tools like Terser support a comments: /^\/*!/ option that preserves comments starting with /*! while removing everything else.
• Dynamic code execution: Code that builds and executes JavaScript from strings at runtime can break when advanced minifiers rename the variables those strings reference. This basic tool doesn't rename variables so it's safe in those cases - but avoiding dynamic code execution in production code is the better long-term approach.
• Minifying already-minified code: Running a basic minifier on code that's already been through Terser or esbuild produces near-zero additional savings. The byte counts displayed by this tool make that obvious immediately.

For the reverse operation, the JavaScript Formatter prettifies minified code back into readable form. For other languages, try the CSS Minifier or HTML Minifier.

Sources

• HTTP Archive Web Almanac - JavaScript
• web.dev - Reduce JavaScript Payloads with Code Splitting
• privatenumber/minification-benchmarks - Terser vs esbuild vs SWC
• MDN - Automatic Semicolon Insertion (ASI)
• Terser - JavaScript Parser, Mangler and Compressor
• Google - Brotli Compression (Reference Implementation)