JS Minifier

What is a JavaScript minifier?

A JavaScript minifier rewrites source into the smallest text that still runs. Comments go. Indentation and line breaks go. Local variable names shrink to a letter or two, because nobody reading the shipped file needs them to say anything. Smaller files transfer faster and parse marginally sooner, which is why almost nothing ships to production in the shape a person wrote it.

This page runs Terser, the same minifier webpack and Vite use, loaded into your browser and executed there. What comes back is real minification rather than a text tidy-up. Local variables are renamed to single letters, branches that can never run are deleted, constant arithmetic is folded, boolean literals are shortened, and consecutive statements are joined into one. Paste JavaScript in and the compressed version lands opposite it, with byte counts on both sides and a percentage saved. Terser parses your code before it rewrites anything, so a syntax error comes back as the parser's own message rather than as output that looks fine and is broken.

When to use it

The case this fits best is a short script with no build step behind it. An inline block at the bottom of a landing page, a cookie-banner handler, the tracking blob a vendor sent over as plain text, a standalone widget served off a CDN and edited by hand. It ships as something you paste into a field, where npm and a bundler config would be more machinery than the task deserves. The same goes for anywhere something is counting characters on your behalf: Google Tag Manager custom HTML tags, CMS theme fields, e-commerce script boxes, email-platform template blocks and admin textareas all impose a size cap. Shaving comments, indentation, and local names off a 3 KB snippet is a real saving when that snippet sits inline in the HTML and is cached with nothing.

If you already have a build step, keep minifying there. The engine is the same either way, so the difference is scheduling: a build runs on every deploy, and a browser tab runs when somebody remembers. Where this page earns its place is everything outside that pipeline, like the snippet that never enters the repo, the file edited directly on a server, or the quick check of how small something gets before you decide whether the effort is worth it. If you are tidying a page's assets, the CSS Minifier does the equivalent pass on the stylesheet next to it.

How this tool works

Terser parses your JavaScript into a syntax tree, applies its compress and mangle passes to that tree, and prints the tree back out as code. Every rewrite is made against that structure, so a regex literal full of braces stays a regex literal and a comment marker inside a string stays inside the string. The two passes do different jobs. Compress works on meaning: it deletes code that can never execute, folds constant expressions, collapses statements together, and rewrites values into shorter equivalents, which is why true and false come out as !0 and !1. Mangle works on names, renaming every local binding to the shortest identifier available in its scope. Top-level names are left alone on purpose, so a function or variable declared at the outermost level of your snippet keeps the name you gave it and stays callable from other scripts on the page.

There are two limits. Minification and obfuscation are separate jobs: the output here is smaller and its local names are gone, but a formatter turns it back into readable code in seconds, so it guards nothing you would rather people did not read. The second limit is that Terser assumes standards-compliant code. It will remove a binding that only looked unused because you were reaching it through eval or a with block. If your snippet does anything that exotic, test the output before you trust it.

Terser is fetched from a CDN the first time you open this page (about a megabyte, cached by your browser afterwards), and everything from that point runs locally. The toolbar shows "Loading minifier..." until it is ready, and whatever you have already typed is minified the moment it arrives. Your code goes nowhere: not uploaded, not stored, no request carrying it to find in your network tab. Privacy matters more on a minifier than it sounds, since the snippets people paste into one carry API endpoints, site keys, and a client's unreleased page logic.

Examples

• A documented function

  Input

  /**
   * Round a price to two places.
   * @param {number} cents
   * @returns {number}
   */
  function toPrice(cents) {
    // avoid float drift
    var value = cents / 100;
    return Math.round(value * 100) / 100;
  }

  Output

  function toPrice(r){var n=r/100;return Math.round(100*n)/100}

  203 bytes down to 61, 70% smaller. The JSDoc block accounts for most of that. Notice though that cents and value became r and n while toPrice kept its name: locals get renamed, top-level declarations do not, so the function is still callable as toPrice from anywhere else on the page.

• A config object

  Input

  /* Feature flags */
  var FLAGS = {
    darkMode: true,     // ships next week
    betaSearch: false,
    maxUploads: 20
  };

  Output

  var FLAGS={darkMode:!0,betaSearch:!1,maxUploads:20};

  115 bytes to 52. Both comments are gone and the booleans are shorter, since !0 and !1 evaluate to true and false and save three characters each. Keys are untouched, because anything at all could be reading them by name.

• Dead code and constant folding

  Input

  function init(options) {
    var DEBUG = false;
    if (DEBUG) {
      console.log("verbose");
    }
    var retries = 2 + 1;
    return options.retries || retries;
  }

  Output

  function init(i){return i.retries||3}

  154 bytes to 37, 76% off, and almost none of that is whitespace. The DEBUG flag is provably false, so the branch goes and the flag goes with it. 2 + 1 folds to 3. The retries variable disappears into the one place it was used. No amount of whitespace stripping gets you anywhere near that.

• DOM code with an absolute URL

  Input

  var API = "https://api.example.com/v1";
  function show(el) {
    el.classList.add("ready");
    el.innerHTML = "Loading";
  }

  Output

  var API="https://api.example.com/v1";function show(a){a.classList.add("ready"),a.innerHTML="Loading"}

  Only 14% off, because there was little to remove, and that is the point. The URL keeps both slashes. classList and innerHTML keep their names, and the two statements are joined with a comma. Text-substitution minifiers are the ones that come unstuck on code like this, reading the slashes inside the URL as the start of a comment. A parser never has to guess, because it knows those slashes are inside a string.

Frequently asked questions

• How do I minify JavaScript online?

  Paste your JavaScript into the input panel and the minified version appears in the output panel as you type. No convert button, no upload, no account. The header shows the byte count on each side and the percentage saved, and Copy Output puts the result on your clipboard. If the code has a syntax error you get the parser message in place of output, so you always know whether what you are looking at is real.

• What is the difference between minification and obfuscation?

  Minification makes code smaller while keeping it functionally identical; obfuscation deliberately makes code hard to understand, using string encoding, control-flow flattening and dead-code injection, and it often makes the file larger in the process. Run minified code through a formatter and readable logic comes straight back. The local names are gone, but the structure is intact, so minifying protects nothing you would rather people did not read.

• Can minifying JavaScript break your code?

  Not through the mangling and whitespace removal itself. Terser parses your code and rewrites only what it can prove is safe, so strings, template literals, regex literals, and automatic semicolon insertion are all handled correctly. The real risk is code that hides its own usage from static analysis. A name reached through eval, a with block, or a string lookup can look unused and be removed on that basis. Ordinary code is safe. Anything doing that deserves a test run.

• How much smaller does minifying JavaScript make a file?

  Commonly 40-70% on hand-written source, varying with what is there to remove. Heavily commented code with plenty of locals can drop by three quarters, while a terse block of DOM calls might only lose a tenth. Bear in mind that a good part of that gain overlaps with gzip or Brotli, which your server is probably already applying, so the saving over the wire is smaller than the percentage shown here suggests.

• Can you build something like this that fits how my team works?

  Yes. If someone on your team is hand-trimming snippets before they go into a tag manager or a CMS field, the fix is usually a minify-and-validate step wired into wherever those snippets get published, rather than a browser tab that somebody has to remember. Zinc Online Solutions does that kind of work as a matter of course. Describe the manual version you are running today and we will cost out replacing it.