JS Minifier

Explain what the purpose of JavaScript minification is.

Minification involves taking a piece of working JavaScript code and converting it into its smallest form, without altering its run-time behavior. It does so by removing elements that are relevant to people who are reading the code but not to the JavaScript engine that's running it:

• Comments — every // and /* */ block, gone.
• Indentation and blank lines — whitespace and line breaks are provided for readability and not execution; whitespaces are removed by a minifier.
• Trailing semicolons, redundant parentheses, and other optional syntax when the code is "compact".
• Variable and function names (in "mangle" mode) — a well named variable such as userAuthToken is converted to something like a. This is the part that will get you most of the size reduction on any reasonably sized file because long descriptive names are great for the developer and a hindrance for the browser.

None of this alters the behaviour of the code; if it doesn't it isn't correct. If minified output doesn't match the source, it's a bug in the minifier or, more likely, a piece of code that is fragile and relies on something that doesn't exist in minified code, such as the .name property of a function.

Minifying JavaScript in 3 steps

1. Your code can be pasted, or a file can be uploaded, .js, .mjs and .cjs are accepted.
2. Click minify. It reads your code and removes any safe code and presents you with the shortened code, and a comparison of how much it saved.
3. Copy or download. Fetch the mined output straight or download it as .min.js to deploy.

Minifying vs. Bundling vs. gzip — how they work together

These three terms are used interchangeably all the time and it helps to understand where each of these terms is placed in a production build:

• Minification reduces the size of the code – same files, smaller size.
• Bundling (with Webpack, Rollup, esbuild, Vite, etc.) merges multiple JS files into fewer files, reducing the number of network requests to which a browser needs to make.
• Compression (gzip or Brotli, as done by your web server) compresses the bytes that are sent on the wire, regardless of what the file contents are.

They're not mutually exclusive, they're complementary; the typical production pipeline will bundle, minify and serve the result gzip- or Brotli-compressed. Even if gzip compresses repeated whitespace and text very well, minifying before compressing still makes sense: the mangled short variable names will give the compression algorithm less unique content to encode in the first place, so it will result in a smaller compression than just gzip.

Will minifying do anything to break anything?

Almost never, provided the minifier properly understands the JavaScript syntax (and not does a dumb find and replace), but there are a few patterns that you should know:

• eval() and with can be unpredictable with mangled variable names as they at runtime refer to the variables by string, not by scope as normal variable. Modern minifiers detect and work around most of these cases automatically, but it's the classic edge case.
• Automatic Semicolon Insertion (ASI) bugs — These bugs are created by the use of JavaScript's unreliable tendency to insert missing semicolons, an issue that can sometimes manifest differently without line breaks. This is avoided by having well-formed code with explicit semicolons.
• Global variable name collisions – if you want to expose a variable in your code in the global scope under a particular name (e.g., window.), then you’ll want to make sure you don’t collide. If you use that name in your minifier (as myLibrary does), be sure to exclude it from the minifier or use an explicit export instead of an implicit global.

None of these are things you'll ever find in everyday use code (which is by far the majority of code you'll be minifying). It's worth knowing about, primarily if you're minifying an older codebase, not built to be minified.

Source maps: don't lose your ability to debug

The problem with minification is that it turns the code you send out into something that you no longer recognize: For example, a stack trace will show a.b(c,d) 1 — but that will be useless when debugging. A source map is a file that contains a correspondence between every location in the minified output and the location in the original source—the file that the browser is actually executing. A source map is a file that will show a map between every position in the minified output and its exact position in the original source—the file that the browser is actually running. Most production builds will produce a source map as well as a minified one — it can be uploaded privately to your error tracking service without shipping it public if you wish.

Minifying JavaScript code is important for your website for good reason.

• Core Web Vitals & Page speed. JavaScript is typically the most costly asset on a page, both in terms of download size and parsing and run-time costs. Load time is a factor in Google's page experience signals (including Core Web Vitals), and smaller JS files means less to download.
• Mobile performance. Mobile devices have lower processing power and slower connections when compared to desktops. It will make a lot more difference to someone using a mid-range phone with a weak signal than it will to a developer with fibre connected laptop.
• At scale, bandwidth comes at a cost. So, even a 30% reduction in the size of your JS bundle can be significant bandwidth savings over a month if your site receives a lot of traffic.
• Better, more secure production code. Mangling of the variable names also makes it a little trickier to read or copy your code, but it's not really a security measure – someone intent on deobfuscating or reverse engineering your minified JS code could still do so. Proper code protection, not minification, should be used if you want to protect your code.

Frequently Asked Questions