How to minify HTML, CSS and JavaScript

The short answer

Minification is a whitespace and comment cleanup. A stylesheet written with one property per line, comments and four space indentation becomes a single dense line that the browser parses identically. Nothing about the result on screen changes; only the number of bytes sent over the network goes down.

The tool below handles HTML, CSS and JavaScript. Choose the language, set Action to Minify, paste your code or open a file, and the result appears on the right with the size before and after and how much smaller it got. Copy it or download it as a file. Your code is processed in the browser and is not uploaded.

What minification removes, and what it must keep

A minifier is only safe if it understands the language well enough to know which characters carry meaning. Removing the wrong space breaks code silently, so the rules differ per language.

Some tools go further than whitespace. JavaScript bundlers such as Terser or esbuild also rename local variables to single letters and drop unreachable code; CSS tools such as cssnano or Lightning CSS shorten colors (#ffffff to #fff) and merge rules. That saves more, but it is a transformation of your code, not just a cleanup, and it belongs in a tested build process. The minifier on this page deliberately stops at comments and whitespace, which is why it is safe to use on any snippet without a test suite.

• CSS: comments and line breaks go, but the space in a descendant selector like .menu a must stay, and calc(1px + 2px) needs the spaces around + and minus. License comments that start with /*! are usually kept.
• JavaScript: comments and indentation go, but strings, template literals and regular expressions must not be touched. In code without semicolons, a line break can end a statement, so some line breaks have to stay.
• HTML: whitespace between block elements goes and runs of spaces collapse to one, but the single space between two inline links in a sentence is visible and must stay. Content of pre and textarea is kept exactly.

How much does minifying save?

Savings depend on how the file was written. Heavily commented, generously indented files shrink the most. These are typical ranges for hand written code before server compression:

Minify or gzip? Do both

Servers and CDNs usually compress text files with gzip or Brotli before sending them, which already cuts CSS and JavaScript by roughly 60 to 80 percent. Compression is very good at squeezing repeated whitespace, so the extra gain from minifying is smaller after compression than before it, often in the range of 5 to 20 percent of the compressed size.

It is still worth doing. Minified files parse slightly faster, comments with internal notes never reach the public, and the savings add up on every page view. Tools like Lighthouse and PageSpeed Insights have long flagged unminified CSS and JavaScript for exactly this reason. Check that compression is actually switched on as well: in the browser developer tools, open the Network panel, click a CSS file and look for a content-encoding response header with gzip or br.

Ways to minify, from one file to a whole site

Which method fits depends on how often the code changes.

• One file or a snippet: paste it into the tool above. Good for inline scripts in a CMS, a stylesheet for an email template, a widget you hand to a client, or checking how much a file would gain.
• A site with a build step: let the bundler do it. Vite, webpack, Parcel and esbuild minify production builds by default, so usually no extra setting is needed beyond running the production build command.
• A site without a build step: many CMS platforms and caching plugins have a minify option, and some CDNs offer automatic minification. Test the pages after switching it on, because aggressive HTML or JavaScript minification is the most common cause of a broken layout or script after enabling such an option.
• Server side frameworks: ASP.NET, Django and Rails all have asset pipelines or packages that minify at publish time.

When minified code breaks, and how to fix it

Most breakage comes from the original code relying on something a minifier changes, or from a minifier that is too aggressive. These are the usual suspects:

• Missing semicolons plus an aggressive JavaScript minifier: a line starting with ( or [ gets glued to the previous line. Keep line breaks (as this tool does) or add the semicolons.
• Two files concatenated after minifying: if the first file does not end with a semicolon, the second can be parsed as a function call. End each file properly or let a bundler join them.
• CSS hacks and unusual syntax: old browser hacks that depend on exact spacing can stop working. Remove hacks you no longer need.
• Code that reads its own text or function names: renaming minifiers break it, whitespace minifiers do not.
• Syntax errors in the source: a minifier cannot fix them. The tool on this page reports unclosed strings, comments and tags with the line and column, so fix the original first.

Good habits

Never edit minified files directly. Keep the readable source in version control and treat the minified copy as a build output that can be regenerated at any time. If you need to read someone else's minified file, switch Action to Beautify in the same tool to get readable indentation back.

If you use a build tool, generate source maps for production. They let the browser developer tools show the original lines when you debug, while users still download the small file.