MINCode Minifier

The transformations involved

Note that identifier shortening applies only to local scope. Names exposed globally and object property names may be referenced from outside, so they're left alone by default — which is why code with long property names doesn't shrink much.

How to use it

1. Paste the code you want to minify.
2. Compare the output size against the original.
3. Use the minified code where you deploy it — and always keep the original separately.
4. For a real service, let your build tool do this rather than minifying by hand. See below.

How minification relates to gzip

gzip and brotli compress by replacing repeated patterns with dictionary references — and the things minification removes, especially indentation and newlines, are textbook repeated patterns that gzip handles extremely well. So a headline like 'minification cut 40%' is measured pre-compression; compare after gzip and the gap narrows considerably.

Minification still matters for two reasons. First, identifier shortening and dead code elimination are reductions gzip cannot produce. Second, the browser parses and executes the *decompressed* code, not the transferred bytes, so a smaller post-decompression size means less parse and compile time. On low-end devices that parsing cost is often more noticeable than download time.

The order, then, is minify and then compress. They're complements, not substitutes.

Why this belongs in your build tool

The decisive weakness of manual minification is the absence of source maps. Without them, a production stack trace reads like 'a.b is not a function' and diagnosis becomes essentially impossible. Build tools emit source maps alongside the minified output, so your error tracker can point at the original code.

Bundlers also perform optimizations with more upside than minification: tree shaking excludes unused modules entirely, and code splitting ships only what the initial load needs. When you use one function from a large library, tree shaking saves far more than minification does.

• JavaScript: esbuild, Terser, SWC (built into Vite, Next.js, and others)
• CSS: Lightning CSS, cssnano (a PostCSS plugin)
• HTML: html-minifier-terser
• Images and fonts: not minification targets — they have their own optimization paths

When minification breaks code

• Code that depends on function names: reading fn.name or branching on a class name behaves differently once identifiers change. Some DI containers and serialization libraries do this.
• Properties referenced as strings: mixing obj["someProperty"] with obj.someProperty while property mangling is enabled produces mismatches.
• eval or with: scope can't be analyzed statically, so nothing can be safely renamed.
• Semicolon-less code: removing newlines can merge two statements into one. Code relying on automatic semicolon insertion needs particular care.
• Lost license comments: MIT and Apache licenses require attribution to be retained. Enable the option that preserves /*! comments.
• Imports with side effects: modules that look unused but act as polyfills get removed. Declare them via package.json's sideEffects field.

What determines the ratio

The same tool produces very different results depending on the code. Files heavy on comments, indentation, and long local variable names can more than halve. Conversely, already-minified code, code dominated by long string literals, and files with data hardcoded inside them barely shrink at all. If your result is disappointing, check how much of the file is strings or data — in that case the fix isn't minification but moving the data into a separate file loaded on demand.

Frequently Asked Questions

Can minified code be restored?

Not fully. A formatter can restore indentation enough to read it, but deleted comments and original variable names are gone. If a source map ships alongside, the original *can* be reconstructed — which also means publishing source maps in production publishes your source. The usual practice is uploading them to your error tracker only, never to a public path.

Does minification obfuscate code?

It makes code harder to read as a side effect, but that isn't its purpose. Minification targets size; obfuscation deliberately complicates control flow to resist analysis, and it increases size and slows execution. Neither protects secrets embedded in client code — an API key in your frontend is exposed no matter what you run over it.

Is CSS minified the same way?

The idea is the same, with extra CSS-specific optimizations: shortening color notation (#ffffff → #fff), normalizing units (0px → 0), merging duplicate selectors, and dropping unneeded prefixes. Selector merging can affect specificity and declaration order, so verify for visual regressions if you enable aggressive options.

How much reduction is normal?

Typical JavaScript loses 30–50% to minification alone, and often ends up at 25–30% of the original once gzip is applied. As described above, the variance by code type is large — tracking your bundle size across deploys is more useful than comparing against an absolute benchmark.

Is my code sent to a server?

No, it's processed in your browser. That said, pasting source from a private repository into a third-party site may conflict with your organization's policy, so check first.

Does HTTP/2 make minification less important?

HTTP/2 addressed the per-request bottleneck, not transfer volume. Fetching many files in parallel got cheaper, so bundling everything into one file matters less — but reducing byte count still matters just as much, and the parse-cost benefit is independent of the protocol.