HTML Minifier

Compression is easy; safe compression is contextual

An HTML minifier reduces source characters that appear unnecessary to delivery: comments, indentation, line breaks, and spaces around angle brackets. Smaller text is convenient for an embedded snippet or a quick payload comparison. Yet whitespace is also data in HTML text nodes, comments can direct build systems, and raw-text elements contain languages with their own syntax. Minification should therefore be reviewed as a transformation, not assumed harmless.

This free online HTML minifier applies one fixed, aggressive sequence. It removes every substring matching an HTML comment, collapses every run of whitespace to one space, removes whitespace immediately inside and outside < and >, then trims the final result. Output updates as you edit and can be copied from the right pane.

The interface includes an Aggressive Minify checkbox. In the current implementation, toggling it reruns the conversion but does not select a different algorithm: the same aggressive operations occur whether the box is checked or unchecked. Treat the checkbox as nonfunctional for output policy rather than assuming it offers a safer mode.

Trace a small fragment through the rules

Input:

<!-- build: card -->
<div class="card">
  <h2>  Status report  </h2>
  <p>Ready <strong>for review</strong> now.</p>
</div>

Output:

<div class="card"><h2>Status report</h2><p>Ready<strong>for review</strong>now.</p></div>

The saved characters are obvious. So is the risk: spaces adjacent to tags are removed by the replacements around angle brackets. The paragraph can render as “Readyfor reviewnow.” This behavior is more aggressive than merely deleting formatting indentation. Always render or diff text-bearing output before shipping it.

The exact transformation order

Understanding the sequence explains both gains and failures.

1. <!-- ... --> blocks are removed across lines.
2. Any run matched by JavaScript \s+ becomes one ordinary space. That includes line endings, tabs, and repeated spaces.
3. Whitespace surrounding each < is removed.
4. Whitespace surrounding each > is removed.
5. Whitespace at the beginning and end of the complete string is trimmed.

No HTML parser constructs a DOM. The tool does not distinguish tags from comparison text, raw-text content, foreign content, or template delimiters. It does not remove optional end tags, redundant attributes, quote marks, or boolean attribute values. It does not minify CSS or JavaScript with language-aware parsers. Its scope is exactly the text replacements above.

What the comment pass can erase

Most explanatory comments are expendable in production, but some comments participate in workflows:

<!--[if IE]>legacy content<![endif]-->
<!-- ko foreach: items -->
<!-- /ko -->
<!-- build:js /bundle.js -->

The broad comment pattern removes all of these. It has no preservation option for conditional comments, Knockout containerless bindings, static-site directives, server-side include markers, test hooks, or build annotations. If a tool recognizes comment syntax as control data, this minifier is not compatible with that source.

Comments written inside script or style text can also resemble HTML comments. Because removal happens over the unparsed document, the minifier does not ask which context contains the character sequence. Review embedded code independently.

Whitespace-sensitive places to test

Inline phrasing content

Spaces before or after a, span, em, strong, and other inline elements often separate words. Whitespace around a tag boundary is removed, which can concatenate visible text.

Preformatted and form content

<pre> and <textarea> preserve or expose source whitespace. Collapsing runs changes code samples, ASCII diagrams, pasted templates, and default textarea values. The tool has no exemption for these elements.

Scripts and styles

Whitespace can separate JavaScript identifiers and CSS tokens. Global collapsing often leaves basic code functioning, but removal around angle brackets and comment-like sequences can still alter content. Template literals, regular expressions, strings, and data payloads need language-aware minification.

Attribute values

Quoted attribute values are part of the same source string. Repeated whitespace inside class, srcset, inline styles, accessible labels, or arbitrary data-* values is collapsed. Sometimes that is equivalent; sometimes exact text matters.

Custom templates

Mustache, Liquid, ERB, JSX-like expressions, and server templates can contain operators or whitespace-sensitive delimiters. This component does not identify those languages. Minify rendered HTML with a suitable pipeline, or use a template-aware tool.

A safe evaluation workflow

1. Work from a generated or disposable copy, not the only editable source.
2. Paste one representative page or fragment into Input Code.
3. Ignore the apparent policy implied by the checkbox; both states currently use the same replacements.
4. Copy output into a test document.
5. Compare visible text, especially boundaries around inline elements.
6. Test <pre>, <textarea>, inline scripts, inline styles, SVG, and template-driven sections.
7. Confirm whether comments carry framework or build meaning.
8. Run HTML conformance checks and application tests.
9. Compare compressed transfer sizes rather than only raw character counts; HTTP Brotli or gzip already compresses repeated whitespace effectively.

There is no Clear or Download control in this component. Edit or select the input manually, and use Copy in the output header. The page begins with an example document so the behavior is visible immediately.

Raw size is not transfer size

Removing characters reduces the uncompressed byte count, but production servers commonly apply Brotli or gzip. Repeated indentation and whitespace compress extremely well, so the network saving can be smaller than the raw difference suggests. Minification can still help caching and parsing costs, but measure the actual artifact under the same content encoding clients receive.

A mature build pipeline can also hash assets, cache output, preserve required comments, and choose parser-aware options. This browser tool reports no byte totals and does not integrate with a build. Use developer tools, Content-Length, or artifact measurement to quantify the result.

HTML syntax and semantic limits

The minifier neither validates nor repairs markup. An unclosed element remains unclosed. Invalid nesting is compressed without diagnosis. The WHATWG HTML parser may recover from malformed input, but recovery can create a DOM unlike the source’s visual nesting. Minification should happen after validation, not instead of it.

The tool also makes no claim of canonical HTML serialization. Attribute order stays as entered, character references stay as entered, void element syntax is not normalized, and optional tags remain. “Minified” here describes whitespace and comment removal, not the complete optimization set found in configurable production packages.

Appropriate uses

This online HTML compressor is useful for demonstrating how a short fragment looks without formatting, preparing a controlled embed whose text has been checked, or quickly comparing a source sample with an aggressively collapsed version. It can also reveal where a project depends on incidental whitespace: if the rendering breaks, those boundaries deserve explicit handling.

Do not use it blindly for email templates, rich text, documentation pages, source containing <pre>, or framework templates. For those, select a parser-aware minifier that understands the target grammar and supports a tested configuration. Keep readable source in version control and generate compressed output during builds.

A release checklist for minified markup

• Visible words remain separated around inline tags.
• Preformatted and textarea content is unchanged where required.
• Necessary conditional or directive comments remain available through another process.
• Embedded JavaScript and CSS still parse and behave correctly.
• Quoted attribute values preserve meaningful whitespace.
• Templates are processed in the intended order.
• HTML validation runs before deployment.
• Brotli or gzip transfer size is measured.
• Readable source, not minified output, remains maintainable.

FAQ about this minifier

What does Aggressive Minify change?

Currently, nothing about the algorithm. Changing the checkbox reruns the effect, but both states perform the same comment removal and whitespace replacements.

Does it preserve license comments?

No. All matched HTML comments are removed; there is no pattern for keeping comments beginning with ! or containing license text.

Will it minify inline CSS and JavaScript?

Only indirectly through global whitespace collapsing. It does not parse either language and should not replace a CSS or JavaScript minifier.

Why did words run together?

The rules remove whitespace next to < and >. Spaces represented by text nodes around inline elements can disappear, joining adjacent words.

Does it remove optional closing tags or quotes?

No. It leaves tags and attributes otherwise intact. Its operations are limited to comments and whitespace.

Can I download the result?

No. The implemented action is Copy. There is no download button on this page.

Is empty input handled?

Yes. When the input is empty, output is cleared. Whitespace-only input is eventually trimmed to an empty result.

Is this safe for <pre> blocks?

No. All whitespace runs are collapsed globally, including text inside <pre>. Use a context-aware process when preformatted content matters.