HTML Minifier — Minify HTML Code Online
Minify HTML code by removing comments, extra whitespace, optional tags, and collapsing whitespace. Reduce file size and improve page load performance. 100% client-side — nothing is sent to any server.
What is HTML minification? HTML minification strips the characters a browser does not need — comments, indentation, line breaks and, optionally, closing tags the parser can infer — without changing what the page renders. It is a text transformation rather than a rewrite: element order, attribute values and visible content all stay as written. How much it saves depends on how heavily formatted the source was, and the gain narrows once gzip or Brotli compression is applied on top.
How to Use the HTML Minifier
- Paste your HTML into the left panel — A full document, a template fragment or a single component all work — nothing is parsed as a document, so the input does not have to be well-formed or complete.
- Start with the two safe options — Remove comments and Collapse whitespace are on by default and account for most of the reduction on hand-written markup. Leave the other two off until you have read what they do.
-
Add optional-tag and quote removal if you need more — Remove optional tags deletes closing tags the HTML parser can infer, such as
</li>and</td>. Remove attribute quotes unquotes values that contain no spaces or special characters. - Press Minify and read the savings tag — The badge above the output shows the reduction as a percentage and as a character count, comparing input length with output length. Toggling any option re-runs the transformation immediately.
-
Check the output before you ship it — Skim for anything inside
<pre>,<textarea>,<script>or<style>, where collapsed whitespace changes behaviour rather than just size. Swap moves the output back into the input if you want to run another pass. - Copy the result — Copy Output or the clipboard icon puts the minified markup on your clipboard, ready to paste into a template, an email builder or a deployment artefact.
What Each Option Does
The minifier is a sequence of text substitutions applied in a fixed order: comments first, then optional closing tags, then attribute quotes, and whitespace collapsing last. It does not build a DOM, so it is fast and works on partial markup, but it also cannot tell markup apart from text that merely looks like markup. The table below is exactly what each checkbox does.
| Option | Transformation | Watch out for |
|---|---|---|
| Remove comments | Deletes everything between <!-- and the next --> |
Legacy conditional comments for old Internet Explorer are comments too and disappear with the rest |
| Collapse whitespace | Reduces every run of whitespace to one space, removes spaces between adjacent tags, and trims the result | Applies inside <pre>, <textarea>, <script> and <style> as well |
| Remove optional tags | Deletes the closing tags </html>, </head>, </body>, </p>, </li>, </dt>, </dd>, </option>, </thead>, </tbody>, </tfoot>, </tr>, </td> and </th> |
Opening tags are untouched. Omission is only always safe when the next element is a sibling the parser recognises |
| Remove attribute quotes | Drops the quotes around a value that contains no whitespace and no ", ', =, <, > or backtick |
An empty value becomes a bare =, which is not valid markup — keep quotes if you have any |
Because the passes run in that order, the options interact. Removing comments first means whitespace that surrounded a comment collapses cleanly instead of leaving a gap. Removing quotes before collapsing whitespace means an unquoted value is never accidentally joined to the next attribute. Turning options on one at a time and watching the savings badge is the quickest way to see which one is actually earning its risk on your markup.
Which Closing Tags Are Genuinely Optional
The HTML specification lets a parser infer certain end tags, which is why </li> and
</td> can be dropped: a new <li> or the end of the list implicitly closes the
previous item, and the same reasoning applies to table cells, rows and sections, to <dt> and
<dd>, to <option>, and to the document-level html, head
and body elements.
The one to think about is </p>. A paragraph closes implicitly when the next thing is a block-level
sibling or the parent ends, but not when it is followed by inline content. Drop the closing tag from
<p>Intro</p><span>note</span> and the span is swallowed into the paragraph,
which changes both the DOM and any CSS selector that depends on it. If your markup mixes paragraphs with inline
siblings, leave this option off — the saving is a handful of bytes and the failure is silent.
Optional-tag removal is applied by pattern matching, so a literal </p> written inside a script string or a code sample using real tags rather than escaped entities is removed too. Escape sample markup as </p> and it is left alone.
Where Whitespace Collapsing Changes Behaviour
Whitespace is not always decorative, and this is the pass most likely to surprise you. Four cases matter.
- Preformatted text.
<pre>and<textarea>render whitespace literally. Collapsing it turns an ASCII diagram or a code listing into one long line. - Inline elements. The space in
</span> <span>is rendered, so removing it joins two words together. Anywhere adjacent inline elements are separated only by a line break in the source, the rendered gap disappears. - Inline scripts. Newlines inside
<script>are collapsed to spaces, so a//line comment now comments out the rest of the script, and any code relying on automatic semicolon insertion across lines changes meaning. Minify JavaScript with a JavaScript minifier, or move it to an external file. - Unescaped angle brackets in text. The pass also trims whitespace adjacent to
<and>, so a comparison written as bare text —if a > b— loses the space around the operator. Escaping those characters as entities, which you should be doing anyway, avoids it entirely.
None of this makes the tool unusable; it makes the output worth a glance. Templates, email HTML and generated pages usually minify cleanly. Documentation pages full of code samples usually do not.
How Much Minification Is Worth
The badge above the output reports the real reduction for the text you pasted, comparing character counts before and after — so you never have to take a general figure on trust. The number varies enormously with source style: markup generated by a templating engine with four-space indentation and a comment on every section loses far more than markup that was already compact.
The figure that matters in production is the compressed one. Gzip and Brotli work by encoding repeated sequences, and runs of indentation are the most repetitive content in a typical HTML file, so a compressor removes much of the same redundancy for free. A file that shrinks by a quarter when minified will usually show a far smaller gap once both versions are gzipped. Minify because the transfer is genuinely smaller and the parse is marginally cheaper, not because of a headline percentage.
The practical workflow is to keep the readable source in version control and minify as a build or deployment step, so comments and indentation stay available to the next person editing the file. This page is for the cases that sit outside a build: a snippet pasted into a CMS field, an email template, an embed widget, or checking what a minifier would do to a fragment before you wire one into a pipeline.
Frequently Asked Questions
With the two default options on, ordinary markup comes through unchanged in structure — comments and formatting go, elements, attributes and text stay. The cases that do change behaviour are specific and predictable: whitespace inside <pre>, <textarea> and <script>, the rendered space between adjacent inline elements, and paragraphs followed by inline siblings when optional-tag removal is on. Compare the two panels before shipping anything you cannot easily roll back.
No, and it is not safe to assume they are left alone either. There is no CSS or JS minifier here, but the whitespace pass runs over the whole document, so newlines inside <script> and <style> blocks are collapsed to single spaces along with everything else. For JavaScript that means a // comment will swallow the rest of the script. Move inline code to external files and minify it with a dedicated tool.
No. Every substitution runs in JavaScript in your tab and no request carries your markup, so the page keeps working offline once loaded. One thing to know: the input and your option settings are written into the page URL so a session survives a reload — that rewrite is local, but the markup is visible in the address bar, so clear the panel before sharing the link.
This tool removes </html>, </head>, </body>, </p>, </li>, </dt>, </dd>, </option>, </thead>, </tbody>, </tfoot>, </tr>, </td> and </th>. The HTML parser infers all of them from the next opening tag or the end of the parent. Opening tags are never removed, and no other element is touched.
An unquoted value must contain no whitespace and none of ", ', =, <, > or a backtick — the tool checks for exactly that set and leaves anything else quoted. The one gap to watch is an empty value: value="" becomes a bare value=, which is not valid markup. If your input has empty attributes, leave this option off.
The savings badge measures your own input rather than quoting an average, because the answer depends entirely on how the source was formatted. What matters more is the compressed size: gzip and Brotli already encode repeated indentation efficiently, so the gap between a minified and an unminified file shrinks considerably once compression is applied. Treat minification as a small, cheap win rather than a performance strategy on its own.
Whitespace collapsing does not know that a block is preformatted, so anything inside <pre> or <textarea> is flattened to a single line along with the rest of the document. If the page is mostly documentation or code listings, either leave collapsing off and rely on comment removal alone, or minify the surrounding template and leave the sample blocks out of it.
Not the comments — those are gone for good, which is why the readable copy should live in version control. The indentation can be reconstructed: paste the minified markup into the HTML Beautify tool and it will re-indent the tag structure. That gives you something readable to inspect, not a byte-for-byte return to the original file.
Use Cases
Trimming a CMS Snippet
Paste a hand-written block into a page builder or CMS field that has no build step of its own, so the markup that ends up in the database is compact rather than carrying an editor's indentation.
Keeping an Email Template Under the Clip Limit
Table-based email HTML grows fast, and some mail clients truncate long messages and hide the rest behind a "view entire message" link. Stripping comments and indentation buys headroom before you cut content.
Stripping Build Comments Before Release
Templating engines and page builders leave debug comments, TODO notes and editor markers in the output. Comment removal takes them out of what visitors can read in view-source.
Fitting an Embed Into a Character Limit
Ad platforms, widget fields and marketplace listings often cap the HTML they accept. Minifying is the least destructive way to fit a snippet under the limit before you start deleting markup.
Previewing What a Build Minifier Will Do
Before wiring minification into a pipeline, run a representative page through here to see which parts of the markup are sensitive to whitespace, and which options you will need to disable.