JavaScript Minifier

Paste JavaScript and get a minified version that is 40-70% smaller, whitespace stripped, variables shortened to single letters, dead branches removed, constants folded, and (if you enable it) comments purged. Useful for quick size checks, one-off embeds and landing pages where you are not running a full build toolchain.

How to minify JavaScript

  1. 1

    Paste the source

    Any valid ES5+ JavaScript. For ES6 and beyond (template literals, classes, modules), make sure your target matches.

  2. 2

    Pick the aggressiveness

    Safe (whitespace + comments), default (+ variable renaming), aggressive (+ mangle properties, may break DOM access).

  3. 3

    Minify

    The tool runs a Terser-compatible transform and outputs the result with before/after byte counts.

  4. 4

    Copy or download

    Paste the output into a `<script>` tag or save as a `.min.js` for serving from your CDN.

Where the bytes go

A typical minified file is 40-70% smaller than the source. Wrapping it in gzip (or Brotli, which Cloudflare and most CDNs use) drops another 60-75%. Combined, a 100 KB source can ship as ~15-25 KB over the wire.

Source Minified +gzip +Brotli
jQuery 3.6 87 KB 30 KB 27 KB
Lodash 4.17 71 KB 25 KB 22 KB
React + ReactDOM 18 140 KB 44 KB 39 KB

Techniques applied

Technique What it does
Whitespace removal Strip spaces, tabs, newlines
Comment removal Delete // and /* */ (unless !important)
Variable mangling Rename userName -> u (scope-safe)
Property mangling Rename obj.foo -> obj.a (UNSAFE)
Constant folding 1 + 2 + 3 -> 6
Dead code elimination Drop branches after return
Control-flow inlining Inline tiny functions used once
String literal compression Merge repeated string constants

Safe vs aggressive mode

  • Safe keeps variable names, only strips whitespace. Good for debugging where you want readable stack traces.
  • Default mangles locals but keeps globals and property names. Works with most code.
  • Aggressive mangles everything, including property names. It often breaks code that accesses properties dynamically (obj["prop"], Object.keys(obj)) unless you configure reserved names.

When to minify: and when not to

  • Do minify in production, on every asset the browser downloads.
  • Do serve a source map so browser DevTools can still show original names when debugging.
  • Don’t minify in development, you waste build time and lose readable errors.
  • Don’t minify already-minified code. .min.js files shrink by ~1-3% on re-minification while risking breakage.

Common mistakes

  • Not configuring reserved names. Dynamic property access (obj["payment_method"]) breaks when payment_method is mangled to a.
  • Forgetting source maps. Without .map files, production errors are unreadable.
  • Minifying CommonJS and ESM together. Mixed module systems need careful tree-shaking before minification.

Frequently Asked Questions

Typically 40-70% smaller uncompressed, dropping a further 60-75% when gzipped or Brotli-compressed. A 100 KB source often ships as ~15-25 KB over the wire.

Default (local-variable) mangling is almost always safe. Aggressive property mangling breaks any code that accesses properties dynamically. Configure the reserved list carefully before enabling it.

Yes, toggle “generate source map” and the tool returns the minified code plus a .map file that maps every byte back to the original source. Upload both to your CDN so DevTools can show readable stack traces.

Yes, top-level await, class fields, private methods, nullish coalescing, optional chaining and numeric separators are all supported. For very new proposals (decorators stage-3), check the specific flag.

Related Tools

Tool available in other languages