Free JavaScript Minifier

Why JavaScript Minification Still Matters in 2026

JavaScript is the heaviest resource type on most web pages, and not just because it tends to be the largest file. The cost is in five stages: download (over the network), parse (the engine reads the bytes and builds an AST), compile (V8 or JavaScriptCore compiles the AST to bytecode), execute (the bytecode runs), and on subsequent visits, warm-start from cached bytecode if the engine kept it. Brotli at the CDN edge handles download cost. Minification helps with download too, but it also helps with parse and compile cost on every device that downloads your script, and on a low-end Android phone, parse and compile can take longer than the network transfer did. Addy Osmani's Cost of JavaScript articles have repeatedly shown that what looks like a network problem is often a CPU problem, and that minification's 20-40% byte reduction translates fairly directly into shaved milliseconds of parse time on the long tail of slow devices.

V8's lazy parsing optimisation defers full parsing of any function until it's actually called, which means a large script with many unused functions costs less than its byte count suggests. Chrome's HTTP cache also stores the V8 bytecode (the "Code Cache") so repeat visits skip the parse-and-compile stage entirely. None of this changes the basic equation: smaller scripts hit warm cache faster, parse faster on the cold path, and compile faster. Minification is the cheapest place on the entire stack to claw back milliseconds.

The Four (or Five) Levels of JavaScript Minification

Not all minifiers are equal, and the level you need depends on your codebase. Level 1: whitespace and comment removal. The simplest pass, strip spaces, tabs, newlines and // ... / /* ... */ comments. This is what a regex pass can do safely (with care around strings, template literals and regex literals). Typical reduction: 20-40% in raw bytes. Level 2: symbol renaming (mangling). Local variable names, function parameters and (with care) function names get rewritten to single letters: function calculateTotal(itemList) becomes function a(b). This requires an Abstract Syntax Tree and full scope analysis to know which names are safe to rename, global names, exports, references to this's properties, and anything reached via string-keyed access (obj['name']) all have to stay intact. Typical additional reduction: 10-25%. Level 3: dead code elimination (tree shaking). Module-level static analysis identifies imports and code paths that never execute and removes them. Requires module-level type information and a clear understanding of side effects. Typical additional reduction: variable, but can be enormous on libraries that ship many features. Level 4: inlining and constant folding. Simple expressions like 2 * 60 * 60 get evaluated at build time to 7200; tiny functions called once may get inlined into their caller. Level 5: property mangling. The most aggressive optimisation, object property names get rewritten too. Breaks any code that uses string keys (obj['name'] vs obj.name) or that exposes property names as part of its public contract. Almost always opt-in and almost always limited to specific identifiers via a --mangle-props regex.

A Short History of JavaScript Minification Tooling

JSMin (2003). Douglas Crockford (yes, the same Crockford who promoted JSON) wrote JSMin in C in 2003. It was a tiny single-file program that did basic whitespace and comment removal with no AST, no scope analysis, and a deliberately conservative approach to ASI (Automatic Semicolon Insertion) edge cases. It set the bar for "the simplest thing that works" and is the spiritual ancestor of every regex-based JS minifier since. YUI Compressor (2007). Yahoo's Julien Lecomte announced the YUI Compressor on 11 August 2007. It used the Rhino tokeniser to do safe symbol renaming, the first widely-used Java tool to do real AST-based mangling for JavaScript. Closure Compiler (2009). Google had been using it internally since 2005; they open-sourced it under Apache 2.0 on 5 November 2009. Closure was the most aggressive optimiser of the era, type-aware via JSDoc annotations, with an "advanced" mode that could rewrite property names based on type inference. The trade-off was that you had to write your code in a Closure-friendly way; advanced-mode failures were notorious.

UglifyJS (~2010-2012). Mihai Bazon's UglifyJS was the first JavaScript-native minifier (written in JS, run on Node.js) and it became the npm default for a decade. UglifyJS 2 added source map support and ES5 features; UglifyJS 3 followed with continued ES5 polish but never fully gained ES6+ support. Terser (August 2018). Fabricio Matté forked UglifyJS into Terser specifically to add ES6+ support without disrupting the long-stable UglifyJS API. Terser is now the default JS minifier in webpack 5, Rollup, Parcel 1, and the older Next.js versions. swc (2017/2019). Donny "kdy1" Choi's swc ("Speedy Web Compiler") is a Rust-based JavaScript/TypeScript compiler with a built-in minifier 20-70× faster than Terser. Next.js switched its default minifier from Terser to swc starting with version 12 in October 2021. esbuild (winter 2019-2020). Evan Wallace, the co-founder of Figma, released esbuild over the 2019-2020 winter holiday. Written in Go, it's 10-100× faster than the JavaScript-based bundlers of the day and ships its own minifier. esbuild is now the underlying minifier in Vite, in tsup, and in many framework templates. The general direction over the last five years has been: parser written in a fast systems language (Rust or Go) → AST-based optimisations → intelligent ES module-aware tree shaking. The browser-pasted regex minifier (like this tool) sits at the bottom of that ladder, doing the simplest job that's still useful.

Source Maps for Minified JavaScript

A source map is a JSON sidecar file that maps positions in the minified output back to positions in the original source. The Source Map V3 spec was authored by John Lenz (Google) and Nick Fitzgerald (Mozilla) in 2011, and was adopted by TC39 as ECMA-426 in June 2024, the same source-map format applies to both JavaScript and CSS. Browsers consume the map via a trailing comment in the minified file: //# sourceMappingURL=app.js.map. When DevTools is open and the map is fetched, the Sources panel shows the original source, with breakpoints, console errors and stack traces all referring back to it. Production minifiers (Terser, swc, esbuild, Closure) all emit source maps on request. This tool does not, for an in-browser one-shot tool that returns text rather than a downloadable file pair, source maps add significant complexity for marginal benefit. The honest disclosure is that this tool is a one-way pass; build-pipeline minifiers have a much stronger case for source maps because the original sources sit on disk and the developer needs to debug at runtime.

Modern Bundler Defaults, Most People Already Have a Minifier

If you're using a modern build pipeline, your minifier is already running. webpack 5 uses terser-webpack-plugin with Terser by default. Vite uses esbuild for minification by default; Lightning CSS for CSS. Parcel uses swc. Next.js switched from Terser to swc in v12 (October 2021), and from Babel to swc for the entire build pipeline in the same version. Remix, Astro, SvelteKit, Nuxt, Rollup, esbuild standalone: all bundle minification into production builds without developer intervention. The result is that for anyone using a modern build pipeline, JS minification happens automatically with optimisations far beyond what a single-file regex tool can do. The cases where this in-browser minifier earns its keep: hand-rolled HTML pages with inline <script> blocks; WordPress themes shipped without a Node toolchain; static-site generators that don't bundle minification; one-off snippets pasted into a CMS or email template; quick experiments where setting up a build pipeline would take longer than the script itself.

Honest Scope: What This Tool Does and Doesn't

This tool is a regex-based minifier, roughly 30 lines of JavaScript. It tokenises string literals, template literals and regex literals into placeholders so subsequent transformations cannot corrupt their contents; strips // ... and /* ... */ comments; collapses runs of whitespace; removes whitespace around punctuation that doesn't need it; and restores the tokenised literals. Typical output is 20-40% smaller than the input in raw bytes. What this tool does not do, and that production minifiers (Terser, swc, esbuild, Closure) handle: it does not rename local variables to single letters (no scope-aware mangling); it does not perform dead-code elimination or tree-shaking; it does not perform constant folding or expression simplification; it does not emit source maps; it does not understand TypeScript syntax (paste only plain JavaScript); it does not tree-shake ES module imports; it does not rewrite property names. The honest framing: paste the JavaScript that came out of your editor or your hand, get back a stripped version that is typically 20-40% smaller in raw bytes, and use it as a quick-deploy artifact. For projects that have a build pipeline, use Terser, swc or esbuild in that pipeline; the AST-aware optimisations are the difference between this tool's 20-40% reduction and a production minifier's 60-80%.

The Regex Minifier's Pitfalls

A regex-based pass that doesn't understand the JavaScript grammar can corrupt code in subtle ways. The classic traps: template literals use backticks and can contain interpolated expressions (`Hello ${name}!`) that look like comment-strip candidates if the regex isn't careful. Regex literals like /^\\/\\*/g contain forward slashes, comment-like sequences, and string-like content; mishandling them turns a regex into syntactically broken code. Strings containing comment-like text (const url = "// example.com"), naive comment removal would strip everything after the //. ASI gotchas: Automatic Semicolon Insertion is the JS feature that lets you omit semicolons most of the time, but it interacts badly with whitespace stripping when the next token starts with a paren, bracket, or operator ((/regex/), [arr], +1), incautious whitespace collapse can change "two statements" into "one statement with a parsing error." The mitigation in this tool is the literal-tokenisation pass that runs first, replacing every string and regex with a unique placeholder, doing the comment+whitespace work on the cleaned-up code, then restoring the placeholders. It's not perfect, but it covers the common cases. If you suspect the minifier broke your code, the first thing to check is a regex literal that contains a slash sequence the tokeniser missed.

Privacy: Why Browser-Only Matters Here

Server-side JS minifiers (online tools that POST your code to a server, run it through Terser there, and return the result) require uploading your source. For ordinary library code this is harmless. For internal tools, unreleased product code, JavaScript containing inline API keys or third-party service credentials, or any code that reveals proprietary algorithms or business logic, it is not. A purely browser-based minifier (JavaScript running in your tab that never makes a network request after the initial page load) sidesteps the issue. You can verify by opening DevTools' Network tab, pasting the code, clicking Minify, and watching for any outgoing request. Better yet, disconnect from the internet (or enable airplane mode) after the page loads and the tool will still work, which is the strongest empirical proof that nothing is being uploaded.

Frequently Asked Questions