What does the JavaScript Minifier do?
A JavaScript minifier rewrites your code into the smallest version that still does the same thing. It strips whitespace and comments, shortens local variable names, and replaces long expressions with shorter ones that mean the same thing. The program behaves the same. The file is smaller.
Here's a real run. Paste these five lines, 89 bytes with their two-space indentation:
function add(first, second) { // sum return first + second;}console.log(add(1, 2));
The output is function add(d,n){return d+n}console.log(add(1,2));, and the stats line reads 89 B → 51 B · 43% smaller. The comment is gone, the spaces are gone, and first and second became d and n. add kept its name, and that's on purpose. More on that below.
The JavaScript Minifier runs terser, the minifier most JavaScript bundlers use under the hood. It runs in a background thread inside your browser tab. Your code is parsed, never executed, and never uploaded. It handles plain JavaScript up to ES2023 and files up to 5 MB. There's no account and nothing to pay.
When you'll want to minify JavaScript
If your project has a build step, your bundler already minifies for you. The JavaScript Minifier is for all the code that lives outside one. That's more code than you'd think.
- The CMS embed. You're pasting a script into a site builder's "custom code" box. Every byte ships on every page view, and there's no pipeline between your editor and production.
- The bookmarklet. A bookmarklet is a whole script crammed into a URL. Shorter code means a shorter URL, and a shorter URL means fewer places for it to break.
- The widget on someone else's site. A chat bubble, a pricing calculator, a signup form for a client. You hand over one file, and it should be small and look finished.
- The one-off. A 2 KB helper that doesn't deserve a
package.json, a config file, and ten minutes of dependency installs. - The sanity check. You want to know how much a file would actually shrink before you bother adding a build step at all.
Most JS minifier pages handle this badly. You paste your code, press a button, and your source goes off to someone's server. The answer comes back wrapped in ads, and some pages want an account before they'll let you download it. The heavy alternative is setting up a whole build pipeline to shrink one file. This page does neither. It works the same whether you're a freelancer shipping a client embed, a student finishing a class project, or a staff engineer who just needs one file smaller before lunch.
How minifying JavaScript works
Terser reads your code into a syntax tree, rewrites the tree, then prints it back out as compactly as it can. Four kinds of change happen along the way.
Whitespace and comments go
Indentation, line breaks, and comments mean nothing to the JavaScript engine, so they're dropped. The one exception is license comments. Anything starting with /*! or containing @license or @preserve stays, because licenses like MIT ask you to keep the notice with the code. The Keep license comments checkbox controls this, and it's on by default.
Expressions get shorter
The compressor folds anything it can work out ahead of time. 40 + 2 becomes 42. true becomes !0, which is 2 characters instead of 4. An if with a one-line body turns into &&. Dead code, like a branch that can never run, gets removed.
Local names get shortened
With Shorten variable names on, every variable and parameter that only exists inside a function gets a one-letter name. Nothing outside that function can see those names, so renaming them can't break anything.
Top-level names stay put
Functions and variables at the top of the file keep their names. That's a deliberate choice. If your HTML says onclick="add()", or another script calls your function, renaming add to a would give you a smaller file that breaks the page. A smaller file that breaks the page is the worst thing a minifier can hand you, so this one won't do it.
The stats line compares your original size with the minified size, both counted in real UTF-8 bytes, not characters. An emoji is 4 bytes, and the count says so. On larger files it also shows the gzipped size of the output, measured by running your browser's own gzip compressor, not estimated. Gzip is roughly what your server actually sends over the wire.
Minified JavaScript examples
Every output below came from the tool with its default settings unless noted.
| Input | Output | What happened |
|---|---|---|
function greet(name) { return 'Hi ' + name; } | function greet(e){return"Hi "+e} | Parameter shortened, top-level greet kept |
export const answer = 40 + 2; | export const answer=42; | Math done ahead of time, export kept |
function tick() { let n = 0; n++; return n; } | function tick(){return 1} | The compressor worked out the answer is always 1 |
if (DEBUG) { console.log('x'); } var y = true; | DEBUG&&console.log("x");var y=!0; | if became &&, true became !0 |
console.log('hi'); var a = 1; console.log(a); with Remove console.* calls on | var a=1; | Both logging calls removed |
var a=1 | var a=1; | Grew by 1 byte (14% larger), because terser always ends a statement with a semicolon |
That last row surprises people. Code that's already minified has nothing left to remove, and terser still adds the semicolon it prefers. The stats line says "larger" and the code is fine.
What each option is worth on a real script
Press Sample and the tool loads a 757-byte price formatter with a license header, two helper functions, a console.log, and a loop over the page. Here's what each setting does to it:
| Settings | Minified | Smaller by | Gzipped |
|---|---|---|---|
| Defaults (names shortened, license kept, console kept) | 419 B | 45% | 295 B |
| Shorten variable names off | 520 B | 31% | 321 B |
| Remove console.* calls on | 380 B | 50% | 273 B |
Look at the first two rows. Shortening names saves 101 bytes of raw file but only 26 bytes after gzip, because gzip is already good at squeezing repeated long names. That's why the gzipped number is the one to watch.
When the minified code breaks, or won't minify at all
If something went wrong, it's usually one of these. Here's what to check first.
You got a parse error
The minifier only reads plain JavaScript. TypeScript and JSX aren't JavaScript until something compiles them. Paste let n: number = 1; and you'll see: "That isn't valid JavaScript. Line 1, column 6: Unexpected token: punc (:)." Column 6 is the colon, the first thing that isn't JavaScript. Compile first, then minify the output. A real typo gets the same treatment: go to the line and column shown, fix that one spot, and it'll minify.
The code does something different now
This is rare, and when it happens the cause is almost always one of three things:
- Your code reads its own names. Code that checks
fn.nameor parsesfn.toString()sees the shortened names. Turn off Shorten variable names. - A console call had a side effect. With Remove console.* calls on,
console.log(count++)disappears, increment and all. - The original relied on a missing semicolon.
var b = afollowed by a line starting with(is one statement in JavaScript, not two. The minifier prints what JavaScript actually does:var b=a(function(){})();. It doesn't "fix" it, because then it would be a different program. If the output looks wrong here, the original was already broken.
Why didn't my top-level variables shrink? Top-level names are kept so HTML and other scripts can still find them. It also means a top-level var DEBUG = false; can't be treated as a constant, since another script could change it. If you want debug code gone completely, wrap your file in a function. Everything inside becomes local and fair game. A 103-byte wrapper holding var DEBUG = false;, an if (DEBUG) log, and window.ready = true; comes out as just window.ready=!0;, 16 bytes.
Tips for smaller JavaScript
- Watch the gzipped number, not the percentage. Turning off name shortening on the sample costs 101 bytes of raw file and only 26 bytes gzipped. Decide what's worth it by the second number. On tiny inputs the gzipped figure is hidden, because gzip's own header makes a small file bigger and servers don't bother compressing files that small.
- Keep the original. Minified code is for shipping, not for editing. Save your readable source, edit that, and minify again. The output updates as you type, so there's no button to press.
- Turn on Remove console.* calls before you ship. It's off by default because some scripts log on purpose. On the sample it takes the file from 45% smaller to 50%.
- Minify JavaScript once. Running an already-minified file through again saves a few bytes at most. Zero percent isn't a failure. It means the job was already done.
- Use Download .min.js when the result is big enough that copying it into a text editor feels risky. It saves as
script.min.js.
Related developer tools
If you're tidying up files before they go to production, the JavaScript Minifier has neighbors. The SVG optimizer does the same job for icons and illustrations, and it's often where the easiest bytes are hiding. When a script works with configuration or API responses, the JSON formatter makes the data readable and can minify it too. To check what an embed actually renders, paste the markup into the HTML viewer. And if your script leans on a pattern you're not sure about, try it against real strings in the regex tester before you ship it.
Frequently asked questions
Does minified JavaScript run faster?
Barely, if at all. When you minify JavaScript, the engine still runs the same instructions either way. The gain is in download and parse time: fewer bytes to fetch and less text to read before the script starts. On a slow mobile connection, that's the part people actually feel.
Is minifying the same as obfuscating?
No. Minifying makes code small, and unreadable is a side effect. Anyone can run it through a formatter and follow the logic again, just with one-letter local names. Obfuscation tries to make code hard to reverse on purpose, and it usually makes the file bigger. The JavaScript Minifier only minifies, like any JS minifier. Don't rely on it to hide anything.
Can I turn the minified code back into the original?
Not fully. Comments and local variable names are gone for good. A formatter can bring back indentation and line breaks, but d and n won't turn back into first and second. That's why you keep your source file and treat the minified one as a build output.
Can I minify ES modules with import and export?
Yes. import and export statements are kept and minified like everything else, so export const answer = 40 + 2; comes out as export const answer=42;. Exported names stay the same, which matters because other files import them by name.
Why does the output use !0 and !1 instead of true and false?
!0 is true and !1 is false in every JavaScript engine, and they're 2 characters instead of 4 or 5. It looks odd, but it's the same value, and every JS minifier does it. You'll see similar tricks everywhere: void 0 for undefined, .08 for 0.08, and && in place of short if statements.
Should I still minify if my server already uses gzip?
Yes. The two stack. The sample script gzips to 413 bytes as written. Minify it first and the gzipped file drops to 295 bytes, 29% less over the wire, because gzip can squeeze repetition but can't delete comments or dead code. Minify, then let the server compress. The stats line shows both numbers so you can see exactly what each step buys you.