JavaScript Minify & Beautify
Optimize your JavaScript bundle size. Minify or beautify instantly.
Why use it
Lighter JavaScript, faster apps
40–60% reduction
Removes whitespace, comments, and shortens variables without altering functionality.
Private
JS is processed in your browser. Never uploaded to any server.
Bidirectional
Minify for production or beautify minified JS to read and debug it.
Instant
Results in milliseconds. No server processing.
How it works
Three steps, no hassle
Paste or upload your JavaScript
Paste JS code directly or drag a .js file. No size limit.
Choose: minify or beautify
Minify for production (reduces variables, removes whitespace) or beautify minified JS to read it.
Copy or download the result
The optimized JavaScript appears instantly. Copy to clipboard or download as a file.
FAQ
Got questions?
JavaScript minification removes whitespace, comments, and line breaks, shortens local variable and function names (renaming/mangling), and in some cases eliminates dead code. The result is functionally identical but significantly smaller, reducing download time and the JS engine's parsing time.
UglifyJS (2010) was the first widely adopted JavaScript minifier, introducing compression and mangling (renaming variables). Terser is the modern successor to UglifyJS, compatible with ES2015+ and ES modules. 'Minify' is the generic term for size reduction. Terser is today's de facto standard, used internally by webpack, Vite, Rollup, and esbuild.
Typically 40–60% of the original size for well-commented and formatted JavaScript. A 200 KB file can be reduced to 80–120 KB with minification alone. Combined with gzip/Brotli compression, total savings can exceed 80%. Variable renaming adds an extra 10–20% reduction beyond simply removing whitespace.
Minified JavaScript can be beautified to recover a readable structure, but renamed variable and function names cannot be recovered: 'calculateMonthlyPayment' may have become 'a' or 'b'. Without the original source maps, the beautified code is functional but hard to understand. Source maps map minified code back to the original and are essential for production debugging.
Source maps are .js.map files that create a correspondence between minified/transpiled code and the original source code. When an error occurs in production, the browser uses the source map to show the stack trace with original names and line numbers instead of the minified version. They are generated automatically by webpack (devtool: 'source-map'), Vite (build.sourcemap: true), or Terser (--source-map).
JavaScript minification history and bundle optimization
JavaScript minification originated with JSMin, created by Douglas Crockford in 2001. Crockford observed that JavaScript sent to the client contained enormous amounts of whitespace and comments consuming unnecessary bandwidth. JSMin was the first systematic compressor: it removed comments and whitespace while preserving language semantics. Shortly after, YUI Compressor (Yahoo, 2007) introduced basic variable renaming, laying the groundwork for modern minification.
Tree-shaking is a related but distinct technique: while minification reduces existing code, tree-shaking eliminates code that is never executed (dead code) by analyzing the ES modules import graph. Rollup popularized tree-shaking in 2015; webpack adopted it in version 2. Code splitting complements these techniques by dividing the bundle into chunks loaded on demand (dynamic import()), reducing the initial JavaScript the browser must parse and execute.
Google's Lighthouse tool includes JavaScript coverage analysis (Coverage tab in Chrome DevTools) that identifies what percentage of downloaded JS is actually executed on initial load. HTTP Archive studies show the median web page loads over 400 KB of compressed JavaScript (1+ MB uncompressed), making it the resource that most harms Time to Interactive (TTI). The adoption of native ESM in modern browsers and the importmaps module pattern represents the next evolution in efficient JavaScript delivery.