Minify or beautify HTML, CSS and JS and see the bytes saved, raw and gzipped.
Language
Action
Names are never shortened, and line breaks that automatic semicolon insertion relies on are kept.
Paste HTML, CSS or JavaScript, or open a file, and choose Minify or Beautify. The language is detected when you paste or open a file, and you can change it. The result shows the size before and after, in bytes and after gzip compression, which is what a server actually sends. Everything runs in your browser.
/*! … */, @license, @preserve) are kept if you like. Names are never shortened, so there is no risk of renaming something another script depends on. The tokenizer knows strings, template literals with nested ${…}, regular expressions (and tells a / b / c from /re/g), and it keeps the spaces that matter: a + +b stays a+ +b, because a++b would be a different program, and 1 .toString() keeps its space. Line breaks that automatic semicolon insertion relies on are kept, for example after return and before ++, so code written without semicolons still works.+ and - inside calc(), and a space before a colon in a selector (a :hover means something different from a:hover) is kept. Strings and url(…) are copied byte for byte.div, p and li is removed. One space always survives between inline elements, so <b>bold</b> <i>italic</i> keeps its gap. <pre> and <textarea> are not touched, attribute values keep their quotes, and inline <style> and <script> can be minified too; JSON-LD and other non-JavaScript scripts are left alone.Beautifying does the reverse: one statement or declaration per line with two-space indentation. Comments are kept.
Whitespace and comments are a large share of hand-written code but compress very well, so the saving after gzip is much smaller than the raw saving. Measured with this tool on React 19.2's development build (react.development.js), the file goes from 47,219 to 32,393 bytes, a third smaller, but gzipped from 10,755 to 9,174 bytes, about 15 percent. A full minifier that also renames variables (esbuild) reaches 7,340 bytes gzipped. If you already serve files with gzip or Brotli and a bundler, this tool will not beat it; it is for a snippet, an email template, an inline script or a quick check of what minifying would change. The article what minification does and doesn't save explains the gzip interplay and source maps.
JSX, TypeScript and template languages (Handlebars, PHP) are not parsed; a character the tokenizer cannot place is reported with its line and column, and so is an unclosed string, comment or regular expression. The HTML minifier does not remove optional closing tags or attribute quotes, which saves a little more but can break pages that are later edited by hand. To check a regular expression, use the regex tester; to tidy JSON, the JSON formatter.
Removing whitespace can, if it is done carelessly: a + +b becomes a++b, and dropping a line break after return changes what is returned. This tool keeps every space and line break that changes how the code parses, and it is tested by checking that minified real libraries parse to exactly the same syntax tree.
Gzip already compresses repeated whitespace and common words very well, so removing them takes away bytes gzip was storing cheaply. A typical hand-written file shrinks 30 to 40 percent raw but 10 to 20 percent after gzip.
No. Renaming saves more, but it needs a full parser and scope analysis to be safe, and it breaks code that relies on names (global functions used from HTML, for example). For production builds use your bundler's minifier.
Yes. Whitespace is only removed next to block elements, where browsers ignore it, and one space is kept between inline elements. Pre and textarea content is kept exactly.
No. Minifying, beautifying and the gzip measurement all happen in your browser.