Minifier / Beautifier
Minify or beautify HTML, CSS, and JavaScript. See size savings before and after gzip. Strip comments, collapse whitespace, restore indentation.
How to Use
- Pick the language: CSS, JavaScript, or HTML.
- Paste your code into the input area.
- Click Minify to strip whitespace and comments, or Beautify to indent and structure.
- Size statistics show original bytes, output bytes, savings, and approximate gzipped size.
- Copy the output with the copy button and use it directly in production or development.
- Round-trip safe — beautifying minified code reproduces a readable equivalent.
What Each Operation Does
A Brief History of Code Minification
Code minification became mainstream with the rise of AJAX-driven web applications in the mid-2000s. Douglas Crockford's JSMin (2003) is generally credited as the first widely-used JavaScript minifier; YUI Compressor (2007) added more aggressive techniques; UglifyJS (2010) and later Terser brought modern AST-based optimization including dead-code elimination, scope-aware variable renaming, and conditional inlining. Google Closure Compiler took the most aggressive approach, doing whole-program optimization at the cost of stricter language requirements.
The golden age of build tools — Grunt, Gulp, webpack, Rollup, Parcel, esbuild, Vite — turned minification from a manual step into a transparent part of every production build. Modern bundlers minify by default; you generally don't write minified code by hand any more. Beautifiers stuck around for the inverse case: reading minified library code in DevTools, or de-obfuscating bundled output.
For HTML specifically, minification has stayed simpler because most of the savings come from gzip compression rather than whitespace removal. CSS gained more sophisticated optimizers (cssnano, csso, lightningcss) that prune unused selectors, merge duplicate rules, and rewrite shorthand notations. The trend has been toward smarter, AST-aware tooling at the build layer; ad-hoc browser tools like this one fill the gap for one-off snippets and learning.
About This Tool
This tool implements simple regex-based minification and beautification — fast and safe for typical hand-written CSS/JS/HTML, but less aggressive than dedicated build-tool minifiers. For production builds use Vite, esbuild, or webpack with Terser/cssnano. For one-off snippets or comparing what minification looks like, this is sufficient.
Everything runs entirely in your browser; code is never transmitted or stored. The size statistics report exact byte counts before and after, plus an approximate gzipped size to help you estimate real-world transfer impact.
Frequently Asked Questions
How much does minification typically save?
Raw size reduction varies by language: CSS 20–30%, JavaScript 15–25%, HTML 10–20%. Gzip compression on top of minification typically reduces the result another 60–80%. The biggest wins come from minifying first then letting the server gzip — but for already-gzipped responses, the marginal benefit of minification is smaller than people often think (gzip handles repetitive whitespace nearly as well as removing it does).
Will minification break my code?
For CSS, no — whitespace is never significant. For HTML, mostly no, but be careful with whitespace-sensitive elements (<code><pre></code>, <code><textarea></code>). For JavaScript, simple minification (whitespace + comment removal, the kind this tool does) is safe; advanced minification (variable renaming, dead-code elimination, the kind UglifyJS or Terser does) can break code that relies on Function.prototype.toString or specific identifier names.
Should I run this in production?
Use a build tool — Vite, esbuild, webpack, or Parcel — for production minification. They handle source maps, tree-shaking, and version management. This tool is for one-off snippets, ad-hoc CSS, or comparing minified vs. unminified output. For real build pipelines, esbuild and Terser produce smaller output than this tool's simple algorithms.
What's the difference between minified and obfuscated?
Minification preserves observable behavior while removing unnecessary bytes (whitespace, comments, optionally renaming local variables). Obfuscation actively makes code hard to read or reverse-engineer, often at the cost of larger size and runtime overhead. Most production minification is just that — minification, not obfuscation. If you need real obfuscation for IP protection, dedicated tools (JavaScript Obfuscator, Jscrambler) handle it.
Why beautify?
Reading minified code is painful — everything on one line, no indentation, often no line breaks at all. Beautifying restores indentation and line breaks so you can debug, audit, or learn from minified code. This won't recover original variable names if they were munged; for that you need source maps.
Does this preserve license comments?
Simple minification strips all comments. Real build tools have an option to preserve comments containing <code>@license</code> or <code>!</code> sentinels, which is required by some open-source licenses (the BSD and MIT licenses require attribution to be preserved). For licensed code in production, use a real minifier or manually add the license back.
Common Use Cases
Reducing CSS file size
Minify a hand-written stylesheet before deploying to a static host that doesn't auto-minify.
Inlining critical CSS
Minify above-the-fold CSS for inlining in the <style> tag of your HTML for fastest first paint.
Reading minified library code
Beautify a minified library you found in production or DevTools to understand what it does.
Preparing email-template HTML
Email clients are notoriously picky; minified HTML reduces parsing differences across them.
Snippet-sharing forums
Beautify minified code from gists or Stack Overflow answers before reading or modifying.
Quick build-output comparison
Run your build tool's output through here to verify the level of minification matches expectations.
Last updated: