Media tools are next. Everything ships the same way: it runs in your tab, or it does not ship.
Code minifiers
Shrink code before it ships. Paste the file or drop it on the page, watch the size drop while you type, then copy the result. Every minifier here runs inside your browser tab, so client code stays client code.
5 tools. All in your browser.
Nothing you paste is uploaded, and once a tool has loaded it keeps working offline. Free, no signup.
JavaScript
2 tools
Both tools run the same Terser build, they differ in how far they go. The minifier leaves top-level names alone, which is what you want for a script other code calls into. The uglifier mangles those too and squeezes out the last few percent, which is what you want for a self-contained bundle. Each shows the original, minified and gzipped size, so you can see whether the extra step was worth it.
Both parse the document before they shrink it, which is what separates them from the regex tools that occasionally eat a rule. The CSS minifier merges duplicate rules only where it can prove the cascade allows it. The HTML minifier knows that a space between two inline elements is rendered, so its conservative mode collapses whitespace instead of deleting it, and it minifies the CSS and JavaScript sitting inside the document with the same engines.
Compacting JSON is the case where the raw byte count is often the whole point: a blob in a database column, an environment variable, a queue message with a size cap. This one parses and re-serialises rather than stripping whitespace with a pattern, so spaces inside your string values survive, and it repairs the near-JSON that strict minifiers reject, comments and trailing commas included.
The parsers ship with the page, so a tool keeps working after you go offline.
Instant, as you type
Every tool runs the moment you type. No run button, no waiting, nothing to install.
Free forever, no signup
No account, no paywall, no trial that expires. All 70+ tools, free for everyone.
Read the gzip number, not the minified one
Every server worth using compresses text responses, so the size that reaches your users is minified plus gzip. jQuery 3.7.1 makes a good yardstick: roughly 285 KB of source, around 86 KB after Terser, around 30 KB on the wire. Minifying removed two thirds, gzip removed two thirds of the rest. A tool that only reports the minified size is telling you half the story.
Two things that break minified code
Missing semicolons are the classic. Automatic semicolon insertion saves you across line breaks, and minifying removes the line breaks. The other is names reached by string: an Angular DI token, a payment provider callback, anything on window. Those need the non-mangling mode, otherwise they are gone. Load the output in a real browser and click through those paths once before it ships.
What minification is worth, and when it hurts
Is minification still worth it when the server sends Brotli anyway?
Yes, and the two multiply rather than compete. Minification removes tokens the compressor would otherwise have to encode, so the compressed output of minified code is reliably smaller than the compressed output of the original, typically by a further 15 to 25 percent on real JavaScript. It also cuts parse and compile time in the browser, which compression does nothing for, because the engine works on the decompressed text. The number to watch is the transferred size after both steps, not either one alone.
Should minification run before or after bundling?
After. A bundler needs readable module boundaries to tree-shake and to deduplicate, and minifying each module first destroys the names it reasons about while producing a worse result overall, since cross-module renaming can no longer happen. The standard order is bundle, then minify the bundle, which is exactly what webpack, Rollup, esbuild and Vite do by default. Pre-minified dependencies from npm are the exception you cannot control, and they are also why some vendor chunks compress worse than your own code.
Can minification break code that uses reflection or dynamic names?
Yes, and name mangling is the usual culprit. Anything that looks a symbol up by string breaks when the symbol is renamed: Angular constructor injection without the explicit annotation, class or function names read through Function.prototype.name, property access built as obj[prefix + key], and serialisation that relies on field names surviving. Mangling top-level and property names are separate options for this reason, and property mangling should stay off unless you have a reserved list.
Do I still need source maps if the code is only minified, not obfuscated?
Yes, if you ever want to read a production stack trace. Minified code puts a whole module on one line, so an error report says line 1, column 84210, which identifies nothing without a map. Generating maps costs build time and no runtime performance, since browsers fetch a .map only when devtools are open, and hidden maps let you keep the file private while your error tracker still symbolicates.
Why did minifying my HTML change the spacing in the rendered page?
Because whitespace between inline elements is rendered as a space, so removing it moves things. The sequence a space b collapses to one space between the links; delete it and the two words touch. The same applies around inline-block and inline-flex items, which is where a navigation bar suddenly loses its gaps. A conservative HTML minifier collapses runs of whitespace but never removes the last one between inline elements, and that is the setting worth keeping.