HTML Minifier: What It Removes and What Can Break

The short answer

An HTML minifier makes a page smaller by deleting comments and the spaces, tabs and line breaks you added for readability. The HTML/CSS Minifier does this instantly and shows the percentage saved. It is safe for plain markup, but check four things afterwards: inline JavaScript, <pre> blocks, <textarea> content and spaces between inline elements such as links, because whitespace-based minifying can change how those behave.

What the HTML minifier removes

The tool's HTML mode applies a few simple rules, in this order:

Deletes every HTML comment, from <!-- to -->.

Collapses every run of whitespace (spaces, tabs, line breaks) into a single space.

Removes whitespace between two tags completely, so </li> <li> becomes </li><li>.

Removes spaces just inside the angle brackets, so <p > becomes <p>.

Trims leading and trailing whitespace.

It does not remove optional closing tags, attribute quotes, default attributes or unused CSS. Your tags and attributes stay exactly as written.

An example

The tool's built-in sample is a small page with indentation and one comment. It is 157 characters before minifying and 108 characters after, a saving of 31.2%. A list like this:

• Before: <ul> on one line, then two indented <li> lines, then </ul>
• After: <ul><li>One</li><li>Two</li></ul>

Savings on a real page depend on how much indentation and how many comments it has. Heavily indented templates save more; already compact HTML saves little.

How to use it

Open the HTML/CSS Minifier. The HTML Minifier tab is selected by default.

Paste your HTML into the left panel. The minified version appears on the right as you type.

Read the savings figure, then click Copy minified.

For a stylesheet, switch to the CSS Minifier tab and paste the CSS instead. For more on that, see how to use a CSS minifier.

What can break, and how to avoid it

Because the rules apply to the whole document, they also touch places where whitespace matters. These examples were run through the tool's own code.

1. Inline JavaScript with line comments

A // comment in JavaScript ends at the line break. When line breaks are collapsed into spaces, everything after the comment on the new single line becomes part of the comment.

• Before: a script with // greet on one line and console.log("hi") on the next.
• After: // greet console.log("hi"), so console.log never runs.

The same problem hits scripts that leave out semicolons and rely on line breaks to separate statements. let a = 1 and let b = 2 on separate lines become let a = 1 let b = 2, which is a syntax error.

Fix: move scripts into separate .js files and minify them with a JavaScript minifier, or use /* block comments */ and semicolons in inline scripts.

2. Preformatted text in pre blocks

Code samples and ASCII tables inside <pre> depend on exact spaces and line breaks. After minifying, a two-line indented block becomes <pre> line 1 line 2 </pre> on one line.

Fix: minify the page without the <pre> sections, then paste the original blocks back in.

3. Default text in a textarea

Line breaks inside <textarea>...</textarea> are part of the default value the user sees. Minifying merges them into one line. The same applies to any whitespace inside attribute values, such as a multi-line title attribute.

4. Spaces between inline elements

This is the easiest one to miss. A space that sits only between two tags is deleted:

• <b>big</b> <i>world</i> becomes <b>big</b><i>world</i> and displays as "bigworld".
• Two links side by side, "Read" and "more", display as "Readmore".
• Inline-block buttons or images that relied on that space for a small gap move closer together.

Fix: put the space inside one of the elements (<b>big </b>), use  , or control gaps with CSS margin instead of whitespace.

Also watch: stray angle brackets in text

The rule that removes spaces after < and before > also runs on text. A sentence containing "a < b" written with a raw less-than sign can turn into something that looks like the start of a tag. Text should always use < and > for these characters anyway.

A safe minifying checklist

• Keep your original. Minified HTML is hard to read and edit. Treat it as build output, not source.
• Diff before and after on a test page. The Code Diff Checker compares line by line, so it is most useful on the original file versus a version you edited by hand.
• Load the minified page in a browser and click through forms, menus and anything that runs JavaScript.
• Check the console (F12 in most browsers) for new JavaScript errors.
• Look at text spacing near links, bold words and icons.

Is minifying HTML worth it?

It helps most when pages have lots of indentation and comments, for example HTML generated from templates. If your server already compresses responses with gzip or Brotli, repeated whitespace compresses very well, so the extra saving on transfer size is smaller than the percentage shown by the tool. Minifying still reduces the uncompressed size the browser has to parse, and removes comments you may not want public, such as internal notes or old markup.

For a typical site, the larger wins usually come from images. Compressing a hero image with Compress Image can save far more than minifying the HTML around it.

Comments you should not delete

The minifier removes all HTML comments. Before minifying, check for comments that do a job:

• Template or CMS markers that a system looks for later.
• Legacy conditional comments for old Internet Explorer.
• Licence notices you are required to keep.

If you need any of these, add them back after minifying.