HTML / CSS / JS Minifier

Why minify?

Every byte you ship travels to every visitor on every page load. Comments, indentation and blank lines are for humans — browsers don't need them. Minification removes them, typically cutting hand-written CSS by 20–40% before compression even starts. Smaller payloads mean faster first paint, better Core Web Vitals, and lower bandwidth bills.

What "safe mode" means here

This tool applies only transformations that can't change behavior: CSS loses comments and inter-rule whitespace; HTML loses comments and between-tag whitespace (while <pre>, <textarea>, <script> and <style> contents are preserved exactly); JavaScript loses comments, indentation and blank lines but is not collapsed onto one line — aggressive JS minification requires a real parser to handle automatic semicolon insertion, and doing it with regexes is how sites break. License banners starting with /*! are kept.

FAQ

Should I minify by hand before deploying?

For anything beyond a quick static page, no — make it part of the build. Bundlers (Vite, esbuild, webpack) minify with full parsers, plus tree-shaking and compression. If you deploy on Abasthan, the build pipeline runs your framework's production build automatically, so minification is handled without thinking about it.

Why is my JS only slightly smaller?

Safe mode keeps one statement per line. The big JS wins (variable renaming, dead-code elimination) need an AST-based minifier like terser — that's a build-step job, not a paste-into-a-textarea job.

Does minification replace gzip/brotli?

No, they stack: minify first, then your server compresses the response. Minified + brotli is typically 70–90% smaller than the original source.