HTML Minifier_
Whitespace and comments removed, and nothing else. Attributes keep their quotes, closing tags stay closed, and no attribute is dropped for being empty — every one of those is a saving that some minifiers take and each one has a way of going wrong.
HTML is the one markup on this site where minifying can change what a reader sees rather than only what a parser reads. The space between two inline elements is rendered; remove it and two words run together on the page. Everything here is built around not doing that.
- Input
- Any HTML — a full page, a fragment, or template output. Conditional comments are recognised and kept, because they are instructions rather than notes.
- Output
- The same markup with collapsible whitespace collapsed and ordinary comments removed. What renders is identical to what rendered before.
- Processing
- Compacted in this tab by a single pass that parks the regions it must not touch, collapses what is left, and puts them back byte for byte.
- Limits
- Whitespace and comments only. No attribute-quote removal, no dropping optional closing tags, no minifying of inline CSS or JavaScript — those are real savings and each is a real risk.
- Whether it is safe depends on your CSS
- A minifier reads your markup and cannot read your stylesheet. Any element styled white-space: pre, pre-wrap or break-spaces renders its whitespace exactly as written — and that styling can arrive from a class, a framework, or a rule three files away. So
and
The markup where minifying is visible
A space between inline elements is content
HTML collapses runs of whitespace to one space, and that one space is rendered. <span>Hello</span> <span>world</span> shows two words with a gap; delete the space between the tags and it shows Helloworld. Between block-level elements the same whitespace renders as nothing at all and can go freely. So a correct HTML minifier has to know which elements are inline — and that is a list, not a rule, which is why minifiers disagree about the edges of it.
Four regions that are never touched
Inside <pre> and <textarea>, whitespace is content the browser renders exactly. Inside <script> and <style> it belongs to a different language with its own rules — and JavaScript in particular can have a line break that inserts a semicolon. All four are parked before anything is collapsed and restored byte for byte afterwards, and the count of how many were protected appears above so you can check it matches what you expected.
Conditional comments are not comments
A comment beginning <!--[if is an instruction that old versions of Internet Explorer acted on, and plenty of email templates still carry them because Outlook uses the Word rendering engine. Stripping them removes behaviour rather than a note. Ordinary comments go; these stay.
The savings this tool declines to take
Serious build-time minifiers offer more: removing quotes around attribute values that do not need them, dropping optional closing tags such as </li>, collapsing boolean attributes to bare words, and minifying the CSS and JavaScript they find inside. Each is legitimate and each has an edge — an unquoted value breaks on a space that appears later from a template variable, and an omitted closing tag changes parsing in ways that are correct by specification and surprising in practice. Those belong in a build that runs your tests, not in a text box.
Measure the saving after compression, not before
The percentage above is the file on disk. What reaches a browser has been through gzip or brotli, and indentation is the single most compressible thing in a document, so most of that saving has already been taken before your minifier runs. Minify because a build does it anyway, because the markup is being embedded somewhere raw, or because a byte limit counts what you hand it — not because the number above translates to the wire.
Paste it, check the protected count
- 01Paste the HTML or upload a file. It minifies as you type.
- 02Check the "untouched regions" figure against how many pre, textarea, script and style blocks you expected. A mismatch means one of them is malformed.
- 03Read any notice above the panes — it appears when the markup contains inline elements separated by whitespace, which is where the visible risk lives.
- 04Compare the size figure against what your server actually sends. If compression is on, the wire saving is a fraction of the file saving.
Markup embedded somewhere raw
A template kept in a database column, a string compiled into a bundle, or an email body. Nothing compresses those on the way to their destination, so the file figure above is the figure you actually get.
<div class="card"> <h2>Title</h2> <p>Body copy here.</p> </div>
<div class="card"><h2>Title</h2><p>Body copy here.</p></div>
The space that is not decoration
Between two inline elements the whitespace is rendered. This is the failure a careless minifier produces, and it is visible to readers rather than to a parser.
<span>Hello</span> <span>world</span>
<span>Hello</span> <span>world</span> <!-- removing it renders "Helloworld" -->
A page with a code sample in it
Everything inside pre is content. Collapsing it would reflow the sample and change what the reader sees.
<p>Run this:</p> <pre> npm install npm test</pre>
<p>Run this:</p><pre> npm install npm test</pre>
An email template with conditional comments
Outlook still reads them. A minifier that treats them as comments removes working behaviour and the failure only shows in one client.
<!--[if mso]><table><![endif]--> <!-- ordinary note -->
<!--[if mso]><table><![endif]-->
What is collapsed, and what is protected
| In the markup | Result | Why |
|---|---|---|
| Indentation between block elements | Removed | It renders as nothing, so nothing is lost. |
| A space between two inline elements | Kept | It renders as a space. Removing it joins two words on the page. |
| Runs of spaces and newlines in text | Collapsed to one | Exactly what the browser does when it lays the text out. |
Inside <pre> and <textarea> | Untouched | Whitespace there is content, and is rendered as written. |
Inside <script> and <style> | Untouched | A different language with different rules — and JavaScript can insert a semicolon at a line break. |
<!-- a note --> | Removed | For the author, not the browser. |
<!--[if mso]> | Kept | An instruction rather than a comment. Outlook still acts on these. |
| Attribute quotes, optional closing tags | Unchanged | Real savings with real edges. They belong in a build with tests behind it. |
The two rows marked as kept for rendering reasons are the ones that go wrong when whitespace is treated as uniformly disposable, and both fail in front of a reader rather than in a validator.
Minifying markup without surprises
- Compare the rendered pages, not the source. HTML minification succeeds or fails visually, so a screenshot before and after catches what a diff of the markup will not.
- Watch for elements you made whitespace-significant in CSS. A rule setting
white-space: pre-wrapmakes an ordinary div behave like a pre, and no minifier can see your stylesheet. - Minify last in the pipeline. Templating engines and post-processors that pattern-match on markup want it laid out; the browser does not care either way.
- Keep conditional comments if the markup is ever sent as email. Outlook renders with Word, and those instructions are how a template survives it.
- Check the saving against a compressed response before adding a build step. Indentation is what a compressor removes first, so the wire gain is far smaller than the file gain.
How minified HTML breaks
Two words run together
The space between inline elements is rendered. This is the most common HTML minification bug and it is visible on the page rather than in any error.
A code sample reflows
Whitespace inside <pre> is content. Anything that collapses it has rewritten the sample rather than compacted the file.
CSS you did not write makes whitespace matter
An element styled white-space: pre renders its spaces exactly, and the rule may live in a framework three files away. A minifier reads markup, not stylesheets.
A conditional comment disappears
Stripping <!--[if …]> removes behaviour that Outlook and older browsers act on, and the failure appears in one client rather than everywhere.
Method, protection and limits
- Method
- A single pass that parks pre, textarea, script and style regions, collapses the whitespace that remains, and restores the parked regions byte for byte.
- Inline elements
- Whitespace adjacent to a, span, strong, em, code, img, button, label and the rest of the inline set is preserved as a single space, because the browser renders it.
- Comments
- Removed, except those beginning with a conditional test, which are instructions rather than notes.
- Not attempted
- No attribute-quote removal, no optional closing-tag omission, no boolean-attribute collapsing, no minifying of inline CSS or JavaScript. Each is a genuine saving with a genuine edge case.
- Limits
- Input is refused above 8 MB; output past 2 MB is truncated for display while Copy carries the whole result.
- File handling
- Uploads are read inside the page with the browser File API and are never transmitted; Download writes out what is already in the tab.
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Questions about minifying HTML
Can minifying HTML change how a page looks?
Yes, and that is what makes it different from minifying JSON or CSS. Whitespace between inline elements is rendered as a space, so removing it joins two words visibly. Whitespace inside pre and textarea is content. Both are protected here — and both are exactly what goes wrong when whitespace is treated as uniformly disposable.
Why is my saving smaller than I expected?
Because indentation is a small share of a real page. Tag names, attributes, class lists and text are the bulk, and none of it can be removed. If the file is still large, look at what is in it rather than at how it is laid out.
Should I minify HTML if the server uses compression?
The gain on the wire is a fraction of the gain on disk, because indentation is the most compressible thing in the document and a compressor removes it first. Minify because your build does it, or because the markup is stored somewhere raw where no compression applies.
Why are quotes still around my attributes?
Because removing them is only safe when the value contains no space, quote, equals sign or backtick — and a value that is safe today can come from a template variable tomorrow. It is a legitimate optimisation for a build tool that can test the result, and a poor bet for a text box.
What happens to my inline CSS and JavaScript?
They are left exactly as written. Both are different languages with different rules, and JavaScript in particular has line breaks that insert semicolons. Minify them with a tool for that language, then minify the markup around them.
Are conditional comments removed?
No. A comment starting with a conditional test is an instruction rather than a note, and Outlook still acts on them because it renders with the Word engine. Ordinary comments are removed; these are kept.
Is minified HTML valid HTML?
Yes. Nothing here changes the structure of the document — only the whitespace between elements, in the places where the browser was going to collapse it anyway. Anything that parsed before parses after.
Does my markup leave the browser?
No. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.