RunToolRunCode Minifier
Minify HTML, CSS, JS code.
How to Minify Code
Paste your code
Drop JavaScript, CSS or HTML into the input field.
Minify locally
Comments, whitespace and line breaks are stripped in your browser.
Copy the compact output
See the before/after size and grab the result.
Minification and compression are different things
Minification rewrites the source: whitespace removed, comments stripped, and in more aggressive tools, local variables renamed to single letters. The output is valid code that behaves identically and is unreadable.
Compression is what the server does on top, and gzip or brotli is remarkably good at repetitive text. This is why the two are not alternatives: minified-then-compressed is smaller than either alone, but the gap between compressed-only and minified-and-compressed is narrower than raw file sizes suggest.
What it actually saves
For CSS and JavaScript delivered to browsers, minification is standard practice and worth doing. Bytes not sent are latency not spent, and on a page loading many files it adds up — particularly on mobile connections, where round trips cost more than bandwidth.
What it does not do is make code run faster once loaded. The engine parses minified and formatted code to the same result; the saving is entirely in transfer and parse time, not execution.
Minified code is not obfuscated code
Renaming variables makes source unpleasant to read, and that is sometimes mistaken for protection. It is not. Any browser will pretty-print it back into readable structure, and the logic remains completely visible.
Anything that must stay secret — keys, credentials, proprietary algorithms — cannot live in code you send to a browser, minified or otherwise. Client-side code is published code.
Debugging what you cannot read
The practical cost of minification is that errors report positions in the minified file, which tells you nothing. Source maps solve this by mapping the minified output back to the original so a browser can show the real line.
Generate them, and consider carefully whether to deploy them publicly: a public source map hands over your original source, which is fine for some projects and not for others. Serving them only to authenticated sessions, or not at all in production, are both common choices.
Where it belongs in a workflow
Minification should be a build step, not something done by hand. Editing minified code is how a project ends up with source and output that have drifted apart, and the drift is only discovered when a fix stops taking effect.
This tool is for one-off cases: a small snippet, a file from a project with no build pipeline, a quick check of how much a file would shrink. It runs entirely in your browser, so proprietary code is not uploaded to a service that may log it.
Test the minified output, not just the original
Aggressive minification can change behaviour in specific circumstances. Code that relies on a function's own name, on the exact text of a function via `toString`, or on automatic semicolon insertion at a line break can behave differently once whitespace and names have gone. These cases are rare, and they are exactly the ones that reach production because nobody thought to check.
The rule that avoids the whole category is to run your tests against the built output rather than the source. A pipeline that tests the source and ships the minified bundle is testing something it does not ship.