JavaScript Minifier

Minify JavaScript with Terser — real compression, right in your browser. See the size saving.

Real minification via Terser, running entirely in your browser — nothing is uploaded.

Free to use — premium coming soon

FREE
  • Terser-powered
  • Size saving
  • 100% private
PREMIUM
  • Remove ads
  • Source maps & options

About the JavaScript Minifier

JavaScript Minifier compresses your script files by stripping out everything the browser does not need to run the code: spaces, tabs, line breaks, and comments. It then rewrites the code into a denser form, collapsing statements and shortening local variable names so getUserPreferences might become a single letter. The behaviour stays identical, but the byte count drops. A typical file shrinks by roughly 20 to 50 percent after minification, which means fewer bytes travel over the network and the browser parses the script sooner. Paste your code, click minify, and copy the compact output.

Reach for this tool whenever you are shipping a small script, an inline snippet, a widget embed, or a standalone file that is not already passing through a build step. Hand-written utilities, third-party tracking tags, and one-off pages rarely get bundled, so they often go to production at full size. Minifying them is a quick win for page speed and Core Web Vitals, because less JavaScript means a faster First Contentful Paint and less main-thread work. It is also handy for trimming code you paste into a CMS field, an email template, or a content widget where every kilobyte counts.

Under the hood this tool uses Terser, a widely used ES6 and newer minifier that parses your code into a syntax tree, applies compression passes, and re-prints it. The compression stage removes dead code that can never run, folds constant expressions, and drops unused variables and functions. The mangle stage renames local identifiers to the shortest safe names. Terser understands modern syntax including arrow functions, classes, template literals, optional chaining, and ES modules, so you do not have to downgrade your code first. Whitespace removal and identifier mangling alone account for the large majority of the size savings on most scripts.

Everything runs in your browser session and the code you paste is processed for minification only, not stored or sent anywhere by us. Standard minification is safe and preserves behaviour, but two caveats are worth knowing. First, code that relies on function names at runtime, such as some serialization or reflection tricks, can break when names are mangled, so test the output before deploying. Second, minified code is hard to debug; keep your readable original under version control, since this one-way transform does not generate a source map for you to map errors back to the source.

Frequently asked questions

Does minifying my JavaScript change how it behaves?

For the vast majority of code, no. Whitespace removal, comment stripping, and local variable mangling preserve behaviour exactly. The rare exceptions are scripts that depend on a function's .name property or on the literal source text, which can break when identifiers are renamed, so always test the minified output.

What is the difference between minifying and gzip compression?

Minification rewrites the source itself into fewer characters, while gzip or Brotli compresses the bytes for transfer and the browser decompresses them back to the same minified code. They stack: minify first, then let your server gzip or Brotli the result, and combined you typically see 70 to 85 percent total size reduction.

Is minification the same as tree-shaking?

No. Minification shrinks the code that is already in a file by removing whitespace and shortening names. Tree-shaking is a bundler feature (Webpack, Rollup, Vite) that removes entire unused modules and exports from the dependency graph before bundling. They are complementary steps, not substitutes.

Will I be able to debug the minified file?

Minified code is very hard to read because variable names are shortened and lines are collapsed. In a real build pipeline you would generate a source map to map errors back to the original. Since this tool outputs minified code only, keep your readable source under version control for debugging.

Does this tool support modern JavaScript like ES modules and optional chaining?

Yes. It uses Terser, which parses ES6 and newer syntax including arrow functions, classes, template literals, optional chaining, and import/export. You do not need to transpile to older JavaScript before minifying.

From our blog

How to Write SEO-Friendly URL Slugs That Last

By the Super Simple Digital Tools Team · Updated June 2026

A URL slug looks trivial, but it is one of the few page elements that is visible in search results, shared in messages, and read aloud by screen readers. Because it is also extremely costly to change after publication, getting it right the first time matters more than for almost any other on-page element. The goal is a slug that a person can read at a glance and instantly understand what the page is about, while staying within the narrow character set that every browser and server handles consistently.

Start from the page's core topic rather than its full title. A headline written for humans often contains filler, dates, and punctuation that add nothing to a URL. Identify the two to five words that genuinely describe the content, then build the slug around them. For an article titled "The 7 Best Ways to Brew Coffee at Home in 2026", a strong slug is simply "best-coffee-brewing-methods". It is short, keyword-rich, and will not look stale next year, which is why baking volatile details like a year into a slug is usually a mistake.

Next, normalize the characters. Convert everything to lowercase to avoid the duplicate-content trap where the same path resolves under different capitalizations. Replace accented letters with their plain ASCII equivalents, strip punctuation and symbols, and collapse spaces into single hyphens. Never use underscores: search engines read them as word joiners, so an underscore-separated slug is interpreted as one long, meaningless token. Stick rigidly to lowercase letters, digits, and hyphens, and your URLs will behave the same everywhere.

Stop words deserve a judgment call. Removing common words like the, and, of, and to usually makes a slug tighter and more focused without losing meaning. But readability wins ties: keep a stop word when dropping it would make the slug confusing or break a familiar phrase such as "how-to-tie-a-tie". The test is simple. If you can read the slug and still understand the page, the stop word can go. If removing it creates a cryptic string, leave it in.

Finally, treat the slug as permanent. Before publishing, check that it is unique across your site, that it has no trailing or doubled hyphens, and that it reads cleanly out of context. If you ever must change a published slug, set up a 301 redirect from the old URL to the new one so you preserve any links and ranking signals the page has earned. A few seconds of care up front saves a tangle of broken links and lost authority later.

  • Paste the human title, then manually delete dates, brand fluff, and filler so the generator works from the three to five words that actually describe the page.
  • Avoid putting years or version numbers in slugs unless they are central to the topic, so the URL does not look outdated next year.
  • After generating, scan for accidental double hyphens or a trailing hyphen left behind by stripped punctuation, and clean them up before publishing.
  • If you change an existing slug, always add a 301 redirect from the old path so saved links and search rankings carry over.

Read the full guide →

Tool by the Super Simple Digital Tools Team. Reviewed by our editorial team. Free to use, no signup required.

Related tools