JS Minifier

No. Minification runs entirely inside your browser using Terser, a JavaScript minifier written in JavaScript itself, compiled to run client-side — there is no server-side component involved in processing your code at any point. This means you can safely paste proprietary application logic, internal utility functions, or unreleased feature code into this tool without it ever leaving your device or being logged anywhere. You can confirm this yourself by opening your browser's developer tools and watching the network tab while you use the tool — you won't see any outgoing requests carrying your code. Even if your internet connection drops after the page has finished loading, the minifier keeps working exactly the same, since it has no dependency on a live server connection to function.

Terser is a widely used, actively maintained JavaScript parser, mangler, and compressor toolkit — it's a maintained fork of the older UglifyJS project, created specifically to add proper support for modern ES6+ syntax (arrow functions, classes, destructuring, async/await) that UglifyJS's original parser couldn't handle. Terser is the minifier bundled by default inside Webpack, Vite's production builds, and Rollup's terser plugin, which means the exact same minification engine powering this tool is the one that actually processes the JavaScript shipped by an enormous share of real-world production websites — it's a mature, extensively tested piece of infrastructure, not an experimental or hand-rolled minifier.

Minification applies three broad categories of transformation. Compression rewrites your code into a logically equivalent but more compact form — removing dead code that can never execute, simplifying conditional expressions, inlining single-use variables, and shortening equivalent syntax patterns. Mangling renames local variables and function parameters to short, meaningless identifiers (a becomes a single letter, a longer name becomes a shorter one) wherever it's provably safe to do so, since the JavaScript engine executing your code doesn't care what a variable is named, only what it refers to. Whitespace and comment removal strips everything that exists purely for human readability — indentation, line breaks, and comments — none of which affects how the code actually runs.

Terser is designed to produce output that behaves identically to your original code in every case it can prove is safe, and it has been battle-tested against millions of real-world production codebases as the default minifier in major build tools — genuine minifier bugs on valid, standard JavaScript are rare. That said, a small number of code patterns are legitimately unsafe to minify automatically, most notably relying on a specific function's name string at runtime (via .name or Function.prototype.toString()) for logic rather than debugging, or code that depends on Function constructor behavior with dynamically-referenced variable names — these patterns break under variable mangling because the whole point of mangling is renaming things, and Terser has no way to know your runtime logic secretly depends on a specific original name. If minified output behaves differently from the original, this dependency on names is the first thing to check.

The stats bar shows the byte size of your input code exactly as typed or pasted, the byte size of the minified output, and the percentage difference between them. This reflects the actual reduction in bytes a browser has to download and parse — a meaningful, direct measure of the network and parse-time cost you're removing from a real production deployment. Keep in mind that gzip or Brotli compression (which virtually every production web server applies on top of minification) tends to shrink minified JavaScript further still and often narrows the gap between minified and unminified compressed sizes, since repeated patterns compress well regardless of whether they're written out with long or short names — minification's biggest win is usually on uncompressed transfer size and parse/execution speed, not solely on the final gzipped byte count.

This is mangling working as intended — Terser renames local variables and function parameters to short identifiers like a, b, or e specifically because shorter names take fewer bytes to transmit and are marginally faster for a JavaScript engine to parse and intern. A JavaScript engine has no concept of a variable being 'meaningfully named'; it only cares about scope and reference identity, so renaming userAccountBalance to a changes absolutely nothing about how your program behaves, as long as every reference to that variable is consistently renamed together — which Terser guarantees by fully parsing your code into an abstract syntax tree rather than doing a blind text find-and-replace. If you need to debug minified code in production, pair it with a source map (which this simple browser tool doesn't generate, but your build pipeline's minification step typically can) to map minified names back to their original source location.

Yes — Terser fully supports modern ECMAScript syntax including arrow functions, template literals, destructuring, classes, async/await, generators, optional chaining (?.), and nullish coalescing (??), since supporting exactly this kind of modern syntax robustly was Terser's original reason for existing as a fork of the older, ES5-focused UglifyJS project. If you paste code using a very recent or still-experimental proposal-stage syntax feature that hasn't yet been finalized into the ECMAScript standard, it's possible the parser won't recognize it — in that case, you'll get a clear parse error rather than silently mangled or broken output.

For any real production project, your build tool (Webpack, Vite, esbuild, Rollup, or your framework's own build step) should minify JavaScript automatically as part of the production build — that's more reliable, integrates with source map generation for debugging, and ensures minification happens consistently on every deploy without a manual step anyone could forget. This tool is most useful for one-off tasks: minifying a single script you're about to paste somewhere without a build pipeline (a bookmarklet, an inline <script> tag, a browser extension content script, a CodePen), quickly checking how much a snippet could shrink, or understanding roughly what minification does to a piece of code you're curious about. It's a utility for ad hoc work, not a replacement for an automated, source-map-aware build process.

No, though they're often confused. Minification's goal is purely reducing file size while preserving behavior — it happens to make code harder to read as a side effect of shortening names and removing formatting, but that's not its primary purpose, and a motivated reader can still fairly easily deobfuscate and understand minified logic by reformatting it and tracing variable usage. True obfuscation is a separate, deliberate practice aimed specifically at making code difficult to understand or reverse-engineer — techniques like string encryption, control-flow flattening, and opaque predicates that Terser's mangler doesn't apply and isn't designed for. If your goal is genuinely protecting intellectual property from reverse engineering (rather than just reducing load time), you need a dedicated obfuscation tool, not a minifier — and it's worth knowing that even dedicated obfuscation only raises the difficulty of reverse engineering, it doesn't make client-side code secret, since the browser executing it always has access to the real logic at runtime.

The achievable savings from minification depend heavily on how the original code was already written. Code that already uses short variable names, has minimal comments, and is written compactly will show smaller percentage gains simply because there's less redundant human-readability overhead left to remove — there's a real floor below which minification can't shrink correctly-functioning code further. Code with long, descriptive variable names, generous comments, and verbose formatting (common and genuinely good practice for source code meant to be read and maintained by humans) tends to show much larger percentage savings, because more of its original size was purely for human benefit rather than something the JavaScript engine needed. A small percentage savings on already-terse code isn't a sign anything went wrong — it usually just means there wasn't much readability overhead to begin with.