JavaScript Minifier & Beautifier Online

What is JavaScript minification?

JavaScript minification is the process of transforming your readable JS source into a functionally identical but byte-smaller version — by stripping whitespace, comments, renaming local variables to single letters, eliminating dead code, and applying compiler-like optimizations. A 200 KB hand-written file typically minifies to 60–90 KB. Combined with gzip/Brotli compression, a 200 KB source can ship as 18–25 KB over the wire.

Minification is the single biggest performance lever for JavaScript-heavy sites. JavaScript is parsed, compiled, and executed on the main thread — bigger bundles mean longer parse times, longer compile times, longer time before the page becomes interactive. Google's Core Web Vitals (specifically INP, TTI, TBT) all penalize bloated JS. Lighthouse flags "minify JavaScript" as a high-impact opportunity, and PageSpeed Insights shows estimated savings.

Three practical wins from minification:

• Smaller download — cuts bytes-over-wire by 30–60% (before gzip), 5–15% incremental win after gzip.
• Faster parse + compile — V8 / SpiderMonkey / JavaScriptCore parse minified code faster because there's less text to tokenize.
• Smaller cache footprint — important on low-storage mobile devices where the HTTP cache evicts assets aggressively.

Minification vs uglification vs obfuscation

These three terms are often confused. They overlap but mean different things in 2026:

For 99% of developers in 2026: you want minification. Obfuscation is for proprietary software where source theft is a real concern; it adds significant runtime overhead and isn't actually unbreakable.

How JS minifiers work — the transformations

What minifiers preserve: top-level (module-level) names exposed via exports, side effects on globals, behavior of every code path, exception types and messages (mostly), reflection-style code (obj[propName] with dynamic propName can't be mangled).

Best JavaScript minifier for 2026 — esbuild vs SWC vs Terser vs oxc-minify

Search results for "javascript minifier online", "minify js online free", and "js compressor" mostly point to text-area generators of varying quality. The 2026 landscape has shifted: Rust-based minifiers (oxc-minify, SWC) and Go-based esbuild are now 10–100× faster than the JS-based Terser, and the gap on compression has narrowed to single digits. Here is the comparison table teams use when picking a minifier today:

How do I minify JavaScript online without uploading my source code?

Paste any JavaScript into the textarea at the top of this page — the entire pipeline (parse → AST transform → variable mangling → whitespace removal → compression) runs in your browser via a Terser-equivalent WebAssembly build. Source code never leaves the page. The same is true of esbuild's online playground (esbuild.github.io/play), Terser's official online tool (try.terser.org), and SWC's playground (swc.rs/playground). Avoid online minifiers that POST your code to a server endpoint — common pattern with ad-funded "minifiers" that index for "compress js online" and silently log everything submitted. Check the Network tab in DevTools before pasting any production code.

What's the difference between minification, uglification, and obfuscation?

Three terms, often confused. Minification removes whitespace, comments, and shortens local variable names — the output runs identically and is roughly readable with a beautifier. Uglification is the legacy term for minification, popularized by UglifyJS — the modern equivalent is Terser, which forked UglifyJS to add ES2015+ support. Obfuscation goes further: it deliberately scrambles code with junk variables, dead branches, control-flow flattening, and string encoding to resist reverse engineering. Obfuscation hurts performance (runs slower) and is an IP-protection layer, not a performance one. For production deploys, you want minification + tree shaking; obfuscation is rarely worth the runtime cost.

JS minifier alternative to javascript-minifier.com — 4 reasons developers switched

1. Both directions in one tool. Minify production code AND beautify minified code from a third-party CDN. Most online tools split these into two separate URLs.
2. Side-by-side size diff. Original size, minified size, gzipped estimate, percent reduction — visible in real time as you type. Forces you to notice when minification gains are marginal (often a sign that imports/tree shaking are the real bottleneck).
3. No code upload. Tools that index for "compress js online" almost universally POST source to a server. Production code in those tools is a confidentiality risk. This page runs the minifier client-side via WASM.
4. No ads, no tracker pixels. Faster paint, no Largest Contentful Paint hit when pasting large files, no third-party JS competing with the minifier worker for the main thread.

Pair the JS minifier with the CSS Minifier and HTML Minifier for the full minification trio, the Web Performance Guide for Core Web Vitals context, and the Byte Converter for translating bundle sizes to mobile-3G download time.

JS minification in 8 build pipelines

esbuild (CLI + JS API)

# CLI
esbuild src/app.js --minify --bundle --outfile=dist/app.min.js \
  --target=es2020 --sourcemap

# JS API
import { build } from 'esbuild';
await build({
  entryPoints: ['src/app.js'],
  outfile: 'dist/app.min.js',
  minify: true,
  bundle: true,
  sourcemap: true,
  target: 'es2020',
});

Vite (built-in)

// vite.config.js — minification on by default in production
export default {
  build: {
    minify: 'esbuild',  // 'esbuild' | 'terser' | false
    sourcemap: true,
    target: 'es2020',
  },
};

Next.js (uses SWC)

// next.config.js — SWC minifier is default in Next 12+
module.exports = {
  swcMinify: true,  // default in Next 13+
  // Or for Terser instead:
  // swcMinify: false,
};

webpack

// webpack.config.js
const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  optimization: {
    minimize: true,
    minimizer: [new TerserPlugin({
      terserOptions: {
        compress: { drop_console: true },
        mangle: true,
        format: { comments: false },
      },
    })],
  },
};

Rollup

// rollup.config.js
import terser from '@rollup/plugin-terser';

export default {
  input: 'src/app.js',
  output: { file: 'dist/app.min.js', format: 'es' },
  plugins: [terser()],
};

Direct Terser (Node)

import { minify } from 'terser';
import { readFile, writeFile } from 'node:fs/promises';

const src = await readFile('app.js', 'utf-8');
const { code, map } = await minify(src, {
  compress: { drop_console: true, pure_funcs: ['console.log'] },
  mangle: { toplevel: true },
  sourceMap: true,
  format: { comments: false },
});
await writeFile('app.min.js', code);
await writeFile('app.min.js.map', map);

SWC CLI

# Install
npm i -D @swc/cli @swc/core

# Minify a single file
npx swc app.js -o app.min.js --config-file .swcrc.minify.json

# .swcrc.minify.json:
# {
#   "minify": true,
#   "jsc": { "minify": { "compress": true, "mangle": true } }
# }

Bash one-liner with esbuild

# If you don't want to install anything globally
npx esbuild app.js --minify > app.min.js

# Or via Docker for ephemeral builds
docker run --rm -v $(pwd):/work node:20 \
  npx --yes terser /work/app.js --compress --mangle > app.min.js

Source maps for production debugging

Minified JavaScript is almost unreadable. When a production user reports "the dashboard crashed at l.k(a,b,5)", that line tells you nothing. Source maps bridge minified code back to your original source — variable names, line numbers, even original file names.

// At the bottom of your minified file:
//# sourceMappingURL=app.min.js.map

// The .map file is JSON with character-level mappings:
{
  "version": 3,
  "file": "app.min.js",
  "sources": ["src/dashboard.js", "src/utils.js", ...],
  "names": ["calculateTotal", "items", "taxRate", ...],
  "mappings": "AAAA;AACA,SAAS,..."  // VLQ-encoded mappings
}

Production source-map strategy

• Always generate source maps in your build pipeline.
• Don't expose them publicly by default — they reveal your source code. Most CI/CD setups upload maps to your error tracker (Sentry, Bugsnag) instead, then strip the sourceMappingURL= comment from the deployed bundle.
• For internal tools, expose source maps publicly — the debug productivity is worth more than the obscurity.
• Use hidden-source-map mode in webpack/esbuild — generates the map file but doesn't add the sourceMappingURL reference. Browsers can't find them, but you can upload to Sentry.

Common JS minification gotchas

• Don't minify in development. Slows down rebuild and breaks debugging. Only minify in production builds.
• Don't minify already-minified files. If you import a vendor lib's *.min.js, your bundler doesn't need to re-minify it. Most do this automatically by detecting "minified" patterns; verify.
• console.log survives by default. Most minifiers don't strip console output unless you configure them: drop_console: true (Terser) or pure_funcs: ['console.log'].
• Don't break Function.prototype.toString(). Some libraries (DI frameworks, dependency injection containers, AngularJS pre-Angular) read function source code at runtime. Use keep_fnames and keep_classnames if you depend on this.
• Mind the "use strict" directive. Hoist it to the top of the output, or your minified module behaves differently from your source.
• Watch out for object property mangling. Default Terser doesn't mangle property names (too risky). Closure Compiler ADVANCED does — it can break obj.foo if you ever access it as obj["foo"] elsewhere.
• ES module exports stay readable. Top-level exports (named or default) preserve their names. Only locals get mangled to single letters.
• Don't over-minify with ADVANCED Closure unless you're prepared to write Closure-style type annotations. ADVANCED rewrites code aggressively — broken behavior is hard to track down without the type info.

JS minification best practices for 2026

• Use esbuild or SWC by default for new projects. 10–100× faster builds = faster feedback loop.
• Always tree-shake before minifying. Removing unused exports is a much bigger win than minification alone — typical savings: 30–70%.
• Code-split aggressively. Don't ship one giant app.min.js. Use dynamic import() for routes, modals, and rarely-used features. Browsers parse fewer bytes upfront.
• Strip console.* in production. Reduces bundle size, prevents accidental info leakage. Configure in your minifier.
• Cache-bust via filename hashing. app.a3f7c2.min.js with Cache-Control: max-age=31536000, immutable.
• Brotli > Gzip on the server. Brotli compresses minified JS ~20% better. Cloudflare and most CDNs support it.
• Audit with Lighthouse. Don't trust eyeballed bundle sizes — Lighthouse and PageSpeed Insights tell you exactly how much each minification opportunity would save.
• Use modern targets. Setting target: "es2020" in esbuild lets the minifier output shorter modern syntax. Targeting ES5 inflates output by 20–40%.
• Set up bundle-size budgets in CI. Block PRs that exceed your budget by 10%. Tools: size-limit, bundlewatch, webpack-bundle-analyzer.