HTML, CSS and JS minifier online
Strip a file down for production or expand a minified one back into something readable, and see the byte count either way.
Runs entirely in your browser. Your code is never uploaded.
Language
How to use the code minifier
- Choose the language first. The three modes use different rules, and running CSS through the JavaScript minifier will produce something broken.
- Paste your code. There is no size limit, though a very large file will take a moment to process.
- Press Minify to strip comments and unnecessary whitespace, or Beautify to re-indent a compressed file so you can read it.
- Check the three counters for the actual saving in bytes and percent, then copy the result. Your original is still in the top box if you want to run it the other way.
What you can use it for
Shrinking a stylesheet or script before it goes live is the obvious one. A hand-written CSS file with comments and generous spacing typically loses 20 to 30% of its weight to minification, and every byte is one the visitor does not download before your page can render.
Reading someone else's minified file is the reverse case and just as common. A plugin ships a single-line 40 KB script, something in it is breaking your page, and you need to see the structure before you can find the problem. Beautifying gives you readable code to work through.
Inline snippets benefit most. Code pasted into a WordPress customiser box, a Blogger template, an email template or a Google Tag Manager custom HTML tag has no build pipeline behind it, so minifying by hand before pasting is the only optimisation available.
It also works as a quick sanity check on unfamiliar code. Beautifying a compressed file reveals its structure — how many functions, how deeply nested, whether it is doing something you did not expect on your page.
Things to know
This is a whitespace and comment minifier, not a compiler. It does not rename variables, remove dead code, or restructure anything the way a full toolchain such as Terser or esbuild does. That means the savings are more modest, and it also means the risk of it changing behaviour is very low.
JavaScript minification here is deliberately conservative. It removes comments and collapses whitespace but does not attempt to remove semicolons or shorten identifiers, because doing that safely requires parsing the entire language including edge cases like automatic semicolon insertion. Conservative and correct beats aggressive and broken.
Strings and regular expressions are protected. Whitespace inside a quoted string is meaningful and is left exactly as written, and a // inside a URL string is not treated as the start of a comment. If your code uses unusual template literal nesting, check the output before deploying it.
Always minify a copy and keep the readable original in version control. Minified code is painful to debug and impossible to review, and the byte saving is a deployment concern rather than something you want in your source tree.
Frequently asked questions
It should not, because only comments and non-significant whitespace are removed. The one real risk is JavaScript written without semicolons that relies on automatic semicolon insertion at line breaks — if the line breaks go, the meaning can change. Test the minified version before deploying it, as you would with any build step.
CSS usually drops 20 to 30%, HTML 10 to 20%, and JavaScript 15 to 40% depending on how heavily commented it was. Gzip or Brotli compression on your server saves considerably more on top of that, and the two combine well — minified code compresses better than unminified.
You can re-indent it and get readable structure back, which is usually enough to debug with. What you cannot get back are the original variable names — if the build tool renamed everything to single letters, that information is gone permanently. Look for a source map instead if one was published.
No. Those are languages that compile to CSS and JavaScript, and they need their own compilers. Minify the compiled output rather than the source.
No. Everything runs in your tab. This matters more than it sounds for code, since scripts and configuration files frequently contain API endpoints, keys and internal URLs that should not be pasted into a third-party server.