Upload a JavaScript (.JS) file and minify it to reduce file size for faster loading and easier distribution.
.js file into the editor, drag-and-drop from your file manager, or paste source directly. The minifier parses any valid JavaScript — single utilities, framework modules, or full bundles. Everything stays in your browser session; no server upload.function checkUser(account) becomes function n(t)), Compress (dead-code elimination, constant folding, boolean simplification like !0 for true, and conditional collapsing), and Remove Console (strip console.log, console.warn, console.error calls). Disable Mangle if your code reads Function.name, calls eval() on local references, or relies on string-based reflection over local names..min.js. Output is ready for production deploy, CDN upload, or embedding inline. Want the reverse for debugging? Paste the result into the JS Formatter to restore readable spacing.JavaScript is the largest blocking resource on most modern pages, and the browser must download, parse, compile, and execute every byte before the script can run. Minification reduces transfer size, shortens parse/compile time, and improves Core Web Vitals — particularly Largest Contentful Paint (LCP) and Total Blocking Time (TBT) for script-heavy pages. Typical end-to-end savings are 50–70% with full mangle + compress, climbing to 80–90% once gzip or Brotli is layered on top. Common reasons to run a minifier:
app.js from 40 KB to 12 KB without configuring a build tool.javascript: URLs — Bookmarklets must fit within the browser's URL-length tolerances (Chrome accepts ~2 MB but legacy clipboards truncate around 2 KB); minification packs the most logic into the smallest URI..js and .min.js precisely because consumers compare the minified size..min.js into the JS Formatter first to make it readable; come back here to re-minify after edits.Numbers below are drawn from privatenumber/minification-benchmarks (updated April 2026 against versions current at that snapshot). "Speed" is relative — lower is faster; "compression" is the typical reduction across the benchmark suite's mix of jQuery, React, Moment, Three.js, lodash, Vue, and TypeScript.
| Engine | Typical compression | Speed | ES2020+ syntax | Source maps | Notes |
|---|---|---|---|---|---|
| Terser | ~66% | Baseline (slow) | Full | Yes | Most widely deployed; reliable on edge cases; default minimizer in Webpack's TerserWebpackPlugin |
| UglifyJS | ~67% (best raw) | Slower than Terser on large inputs | ES5 only | Yes | Highest absolute compression on classic libraries; rejects modern syntax outright |
| esbuild | ~65% | 10–100× faster than Terser | Full | Yes | Go-based; faster but accepts the trade-off of 1–2% larger output |
| swc | ~66% | ~3–8× faster than Terser; close to esbuild | Full | Yes | Rust-based; near-Terser compression at near-esbuild speed; default in Next.js production builds |
| oxc-minify | ~66% | Fastest in the benchmark suite | Full | Yes | Rust-based; Vite 7+ default per the Vite build-options docs (cited as "30–90× faster than Terser, 0.5–2% worse compression") |
| Google Closure (advanced) | ~67%+ | Slowest by orders of magnitude | Full (but strict) | Yes | Aggressive type-aware optimizations; requires annotations and can break code that isn't written for it |
XConvert's in-browser engine targets Terser-grade output (full mangle, compress, dead-code elimination) on files small enough to process client-side without a worker stall — practical up to a few MB of source. Above that, a CLI/CI integration of esbuild, swc, or oxc-minify will be faster.
| Transformation | Example before | Example after | Typical contribution |
|---|---|---|---|
| Whitespace + comments | // returns userfunction getUser(id) { return db.find(id);} |
function getUser(id){return db.find(id)} |
10–25% of savings |
| Identifier mangling | function checkUser(account){return account.isActive} |
function n(t){return t.isActive} |
20–40% of savings (largest single contributor) |
| Dead-code elimination | if (false) { logDebug() }return x;unreachable(); |
(removed) | Varies; large in code with feature flags |
| Constant folding | const TIMEOUT = 1000 * 60 * 5; |
const TIMEOUT=3e5; |
Small but accumulates |
| Boolean / literal shortening | true, false, undefined |
!0, !1, void 0 |
A few percent |
| Conditional collapsing | if (a) { b(); } else { c(); } |
a?b():c() |
A few percent |
| Console / debugger stripping | console.log(state); debugger; |
(removed) | Varies; security plus size |
Mangling only renames identifiers the minifier can prove are local. Globals, exports, property accesses, and anything reached via string lookup (window["onUpload"], obj["fooBar"]) are never touched, because doing so would break external references.
It depends on what you're optimizing for. Terser produces 1–2% smaller output and handles edge cases (legacy browsers, exotic syntax) more conservatively, but it is the slow end of the field. esbuild is 10–100× faster than Terser and is good enough for almost every web app — the size delta is single-digit percentages and disappears entirely after gzip/Brotli. If your CI build is dominated by minification time, switch to esbuild, swc, or oxc-minify. If you ship a library where every byte counts in npm's "minified + gzipped" badge, stay on Terser.
No. The minifier parses your source into an Abstract Syntax Tree, applies transformations on that tree (renaming nodes, dropping branches, folding constants), and serializes the tree back to text. At no point is your code eval()d or run. Side effects like network requests, DOM access, or console.log calls never fire during minification — they're just text edits.
Source map generation is on the roadmap for the browser-based tool. In the meantime, CLI runs of Terser, esbuild, swc, or oxc-minify all emit .map files alongside the output — pass --source-map (Terser) or --sourcemap (esbuild). Browsers load the map when the minified file ends with //# sourceMappingURL=..., so DevTools' Sources panel shows your original code and stack traces deminify correctly.
Three patterns commonly break after mangling: (1) Function.name lookups — frameworks that key off function names (some DI containers, older Angular pre-1.3, certain test runners) see n instead of checkUser. Disable Mangle or add the name to the reserved list. (2) eval() with references to local identifiers — eval("checkUser()") won't find n after mangling. (3) Reflection over local properties — generally safe because Mangle leaves property names alone, but Mangle Props (a separate, opt-in pass in Terser) renames properties too and is the usual culprit when an object key disappears. Class method names are NOT mangled by default in Terser unless you explicitly enable keep_classnames: false and mangle reaches into properties.
Yes for Terser, esbuild, swc, and oxc-minify — all four parse and emit modern syntax including ?., ??, ??=, ||=, &&=, top-level await, private class fields (#x), and class static blocks. UglifyJS is ES5-only — it will throw on let, arrow functions, or any ES6+ syntax, so it's the wrong tool for modern code unless you transpile first with Babel.
Probably not for application code. Webpack in mode: 'production' enables TerserWebpackPlugin by default per the optimization docs. Vite 7+ defaults to oxc-minify. Rollup doesn't minify by default but virtually every Rollup config includes @rollup/plugin-terser. Next.js, Nuxt, and Remix all minify automatically. The remaining real use cases are: ad-hoc files outside any build pipeline, third-party .js you want to inspect or re-pack, bookmarklets, and post-bundle squeeze passes on already-minified vendor files.
No. Names you export — export function foo(), module.exports = { foo }, or assignments to window.foo — are part of the public API and the minifier leaves them intact. Only identifiers the parser can prove are local (function parameters, let/const bindings inside functions, local function declarations) get the single-letter treatment. If you want module-level names also mangled (for bundles that aren't going to be imported by external code), Terser exposes toplevel: true, off by default precisely because it breaks importers.
Not here — this minifier expects standard JavaScript. Compile TS to JS first with tsc, esbuild --loader=ts, or any bundler, then run the output through the minifier. Type annotations, interfaces, decorators, and enums aren't part of the ECMAScript spec, so an AST parser written for JS will reject them.
No. Parsing, mangling, and serialization run entirely in your browser using a client-side AST engine — no network round trip. Sensitive code (API keys in test files, unreleased features, internal SDK source) stays on your device. You can also use sibling tools — JSON Minifier, CSS Minifier, and HTML Minifier — under the same client-only model.