Shrink HTML by removing comments and whitespace between tags, with an optional aggressive pass that collapses spaces in the rest of the document.
<script>, <style>, <pre>, and <textarea> blocks are preserved as-is before minifying the surrounding markup. Everything runs in your browser.
No file loaded
Aggressive mode runs after the two options above and replaces any run of spaces, tabs, or newlines with a single space in the outer markup (placeholders keep
<pre> / <textarea> / <script> / <style> bodies unchanged). Verify output if your HTML is unusual.
Minification reduces file size by removing characters that browsers usually ignore for layout: extra spaces, newlines between tags, and sometimes HTML comments. Smaller payloads can speed up transfers slightly; the main win is often cleaner deploy artifacts when you do not need human-readable source in production.
DroidXP’s HTML Minifier uses pattern-based transforms, not a full DOM parse. It temporarily extracts <script>, <style>,
<pre>, and <textarea> regions (case-insensitive tags), minifies the remaining string, then puts those blocks back unchanged. That avoids mangling
whitespace inside preformatted or script content in the common case.
<!-- … --> (non-greedy matches).> and < into nothing.
Regex minifiers can mis-handle edge cases: for example a <script> string literal that contains the text </script>, or deeply nested custom elements. For
production builds, teams often use established pipelines (for example html-minifier, bundlers, or CMS export tools) with full parsing and tests.
No. The tool runs entirely in your browser. For proprietary templates, still follow your organization’s policies on using web-based utilities.
<pre> or code block change?
Content inside <pre> and <textarea> is shielded before minification. If you still see changes, check for malformed tags, or disable
Aggressive mode — it collapses whitespace in markup that was not inside a protected block.
Whole <script>…</script> elements are preserved as extracted blocks. Edge cases exist when a script contains a substring that looks like a closing
</script> inside a string — that is a known limitation of regex-based tools.
Probably not byte-for-byte. Build tools may reorder attributes, remove optional tags, or minify inline CSS/JS. This page focuses on whitespace and comments for quick checks.
Very large documents may hit memory limits in the tab. This page caps input length; for huge sites, use a CLI or your CI pipeline.
Usually not: browsers collapse inter-element space in normal flow. Exceptions include <pre>, white-space CSS, and inline formatting — which is why protected
blocks and conservative options matter.
File size is a minor factor compared to content quality, Core Web Vitals, and crawlability. Minification can help a little; it is not a substitute for good structure and performance work.