Free online JavaScript minifier. Compress and shrink JS with Terser to cut file size, strip comments, and speed up page loads. See byte savings instantly.
Runs entirely in your browser — no code is uploaded. Beautify re-indents your script with consistent spacing and one statement per line (powered by js-beautify). Minify uses terser to safely compress and rename local variables, strip comments, and remove whitespace — producing the smallest valid output for production.
Paste a script into the left pane and the minified result appears on the right as you type. The bar above the panes
reports the trade in real numbers — for the sample this page loads by default,
Minified: 292 → 222 bytes (−70, 24% smaller). Copy the output with one button. Nothing is
uploaded: the minifier is compiled to JavaScript and runs in your browser tab, so proprietary code, a script with an
API key still in it, or a client's bundle can all go through it without leaving your machine.
The page opens in Minify mode, and the toggle at the top left switches to Beautify, which does the opposite job — re-indenting a compressed script at 2 spaces, 4 spaces, or a tab. The two share one input box, so you can minify, look at the result, and expand it again without re-pasting.
Minification here is terser, the standard JavaScript compressor that the major bundlers use for production
builds, running with compression on, name mangling on, and comment output off. That is a real minifier, not a
whitespace stripper, and it is worth being precise about the three separate things it does, because they carry
different risks.
| Stage | What it removes or changes | Risk |
|---|---|---|
| Formatting | Indentation, line breaks, optional semicolons and braces, all comments | None — the parser ignores this material anyway |
| Compression | Dead code, unreachable branches, unused locals; folds constants; inlines single-use variables; rewrites statements into shorter equivalents | Low, but it changes the shape of your code |
| Mangling | Renames local variables and function parameters to one or two characters | Low as configured here — see below |
On the built-in sample, all three are visible at once. The comment goes. function greet(users) becomes
function greet(e) — the parameter renamed, the function name kept. The
if (...) { return 'nobody here'; } loses its braces. And the intermediate const names = ...
disappears entirely, its expression inlined into the return that used it once. Same output, 70 fewer
bytes.
Renaming is where minifiers earn most of their savings and all of their reputation for breaking things. The logic
is simple: a variable that is only visible inside a function can be called anything, because the compressor can see
every reference to it in the same file and rewrite them all together. A name that is visible outside the file cannot,
because the other references are somewhere the minifier has never looked — another script tag, an inline
onclick, a test suite, a plugin someone else wrote against your library.
This tool is configured conservatively: top-level declarations are not renamed. Confirmed against the actual behaviour — give it
function calc(rate, qty) { var total = rate * qty; return total; }
window.calc = calc;
— and you get back function calc(c,n){return c*n}window.calc=calc;. The parameters became
c and n; the exported name calc survived on both sides. Feed it a function
attached to a string handler, document.body.setAttribute("onclick", "handler()"), and
handler keeps its name too. The classic "the minifier broke my global" failure does not happen with these
settings, which is the right default for a script you are going to drop into a page rather than feed to a
bundler.
The hazards that remain are narrower, and they all come from references the compressor cannot see:
new Function("return total")
compiles at runtime and is opaque to the compressor. In a test, a local total used only that way was
treated as unused and deleted outright — the minified code kept the string and lost the variable, which throws
at call time. Same class of problem for a name looked up dynamically as window[someString] or
this[key] where the key is assembled at runtime.obj.name,
{name: 'Ada'} and data["user_id"] keep their keys. This matters because objects you
JSON.stringify or send to an API must keep their field names, and they do.eval is handled, not ignored. Terser detects eval in a scope and
stops mangling that scope — a local secret read back via eval("secret") keeps its
name in the output. It is still worth removing the eval, because the whole enclosing function loses the
savings./*! ... */ convention
that build tools preserve by default is not preserved here. If your file carries a required attribution header,
re-add it to the output before shipping.These get conflated constantly, and the distinction decides whether minifying is worth doing.
Minification transforms source into shorter source. The output is still valid JavaScript: you can read it, a browser parses it directly, no decoding step is involved. Compression — gzip, or Brotli — is applied by your web server per response, produces bytes that are not JavaScript at all, and is reversed by the browser before the code is parsed. They are independent, they stack, and you want both.
What is easy to miss is how much they overlap. Gzip is very good at repeated strings, and long descriptive identifiers repeated across a file compress extremely well — so the byte count a minifier reports overstates the saving on the wire. Measured on the sample this page ships: 292 bytes of source minify to 222, a 24% cut, but gzipped those two files are roughly 208 and 180 bytes — a gap closer to 13%. (Exact gzip sizes vary by a few bytes between implementations and compression levels.)
The practical reading: minify because it is free and it stacks with compression, but if a page is slow, the minifier is not where the seconds are. Number and size of requests, images, blocking third-party scripts, and code you ship but never execute all dwarf it. There is a second benefit worth more than the bytes on large files — less source is less for the browser to parse before it can run anything.
Minified code is unreadable in a debugger by design: the stack trace says e is not a function at line
1, column 4,102. A source map is the side-car file that maps those positions back to your original file, so DevTools
can show you the code you wrote.
This tool does not generate one. It produces minified code and nothing else, which is the right
fit for its actual use — a script you are pasting into a page, an inline snippet, a quick check of how small a
file gets. If you need source maps, you need the minifier inside a build pipeline, where it can name the map, emit it
alongside the output, and append the //# sourceMappingURL= comment. A useful habit either way: keep the
unminified source in version control and treat the minified file as a build artifact, never as something you edit.
The minifier parses JavaScript, which means it parses JavaScript and nothing else. Verified limits:
let, const, arrow functions, classes,
template literals, async/await, and ES module import/export all
parse and come through.interface or a type annotation produces a parse error.
Compile to JavaScript first.<div /> is not valid JavaScript; a
Unexpected token: operator (<) is what you get.<script> element, not
the element.Syntax errors are reported precisely rather than silently swallowed. A stray semicolon in
const a = ; comes back as Unexpected token: punc (;) (line 1, col 10) in a red bar, and the
output pane stays empty — you never get half-minified code that looks plausible and fails in production.
The second tab expands compressed code instead. It re-indents to your chosen width, puts one statement per line, and keeps at most one blank line between statements, so a wall of code gets some paragraphing back. It is a formatter, so it works on the text: it cannot recover the variable names a mangler discarded, and it cannot restore code the compressor deleted. Beautifying minified output gives you readable structure with one-letter names — genuinely useful for reading a third-party script or working out what a bundle is doing, but not a way back to the original source. For that, use the source map, or the file in your repository.
if/return
pair into a ternary.Minification removes everything a browser does not need to execute your code — comments, whitespace, and long variable names — to make the file as small as possible. Smaller files download and parse faster, improving page load times and Core Web Vitals.
This tool uses Terser, which parses your code into a real syntax tree before transforming it, so the minified output behaves identically to the original. It understands scope, so renaming local variables never causes collisions, and it leaves global functions and object properties untouched. If your code has a syntax error, the tool reports it instead of producing broken output.
It depends on the code, but minification typically removes 30–60% of a file's size before gzip compression. The tool shows you the exact byte savings and the percentage reduction after each run. For even better results, serve the minified file with gzip or Brotli enabled.
They are opposites. Minifying shrinks code to the smallest valid form for production, while beautifying expands it with indentation for reading. Keep readable source in version control and minify only as the final deploy step; use the JavaScript formatter when you need to read a minified file.
No. Compression happens entirely in your browser, so your source code never leaves your machine. It is safe to minify private or proprietary scripts here.