HTML Minifier

Q: Why is whitespace inside a tag not always safe to remove?

Because in HTML whitespace between inline elements is meaningful — it renders as a space. Removing the newline between two spans joins the words together, so "Hello" and "world" become "Helloworld". Whitespace between block elements like divs and list items has no visual effect and is safe to collapse. This minifier only collapses runs of whitespace to a single space rather than deleting it entirely between inline content, which is what keeps the rendered output identical.

Q: What happens to content inside pre and textarea?

It is preserved exactly, character for character. Those elements, along with script and style, render or execute their contents literally, so collapsing whitespace inside them visibly changes the page or breaks the code. A minifier that treats the document as one flat string will happily destroy the indentation in a code sample or introduce a syntax error in an inline script. The parser here tracks which element it is inside and leaves those regions untouched.

Q: How much smaller should I expect the output to be?

Typically 10 to 30 percent for hand-written markup with normal indentation, and less for machine-generated HTML that is already compact. The savings come almost entirely from indentation and line breaks, so deeply nested templates gain the most. It is worth putting that in perspective though: gzip or brotli compression, which every web server should already have enabled, removes most of that redundancy anyway. Minifying on top gives a real but modest additional saving.

Q: Should I minify HTML at all if I have compression enabled?

It helps, but far less than people assume. Compression algorithms are extremely good at collapsing repeated whitespace, so the gain from minifying before compressing is usually a few percent rather than the raw figure you see here. The stronger arguments for minifying are for inlined HTML inside a larger payload, for email templates where compression is not available, and for very high-traffic pages where a few percent is worth having. For a typical site, enabling compression matters far more.

Q: Are comments always safe to strip?

Almost always, with two exceptions worth knowing. Conditional comments targeting old versions of Internet Explorer are functional markup rather than notes, though they are irrelevant on any browser still in use. More importantly, some templating and framework systems use comment markers as placeholders — server-side include directives and certain hydration markers are real comments that the system depends on. If your build pipeline uses anything like that, minify before those markers are inserted rather than after.

Q: Does this change how my page renders?

It should not, and that is the design constraint. Whitespace is collapsed rather than removed between inline content, preserve regions are left alone, and no attributes or tags are rewritten or dropped. The output is intended to be byte-different and pixel-identical. If you do see a rendering change, the most likely cause is markup that was relying on a specific whitespace arrangement between inline elements, which is fragile regardless and worth fixing at the source.

Strip comments and collapse whitespace from HTML without changing how it renders, with the exact byte saving reported.

HTML (0 chars)

Collapse whitespace Remove comments

Minified (0 chars)

Minification runs entirely in your browser. Your markup is never uploaded, and the output is intended to render identically to the input.

What It Does

Paste HTML and get a smaller version of it back that renders identically. The saving comes from the indentation and line breaks that make source readable and mean nothing to a browser, plus comments that were written for people rather than machines. The care is in what it refuses to touch. Content inside pre, textarea, script and style is preserved exactly, because those elements render or execute literally and collapsing whitespace inside them changes the page or breaks the code. Whitespace between inline elements is collapsed to a single space rather than removed, because in HTML that space is visible text — deleting it joins words together. The result is reported with the exact byte count before and after, so you can judge whether the saving is worth having.

When to Use It

You are inlining HTML into a larger payload where every byte counts and compression is not available.
An email template needs to be as small as possible because mail clients do not compress and some truncate long messages.
You want to see how much of a page's weight is indentation before deciding whether minification is worth adding to a build.
A generated fragment is being embedded in JSON and the whitespace is inflating the surrounding document.
You need to compare two pieces of markup for structural equality without whitespace differences getting in the way.

Worked Examples

<div>
    <p>Hello    world</p>
    <!-- a note -->
</div>

The straightforward case. Indentation collapses, the comment disappears, and the run of spaces inside the paragraph becomes one — because a browser was only ever rendering one anyway.

<p>Some <em>emphasis</em>
<strong>and more</strong></p>

The trap. The newline between the two inline elements renders as a space, so it is collapsed to a single space rather than removed. Deleting it entirely would join "emphasis" and "and" into one word.

<pre>
  indented
    code
</pre>

A preserve region. Everything inside pre is left byte for byte, since collapsing it would visibly destroy the formatting that is the entire point of the element.

Features

Whitespace collapsed without joining inline words

Comments removed with a toggle

pre

textarea

script and style preserved exactly

Byte count before and after with the percentage saved

Element and attribute counts reported

Warning when the input is already minified

Handles fragments as well as whole documents

Paired with the HTML formatter for the reverse operation

One-click copy of the result

Runs entirely in your browser

How to Use

1. Paste your HTML into the input box. 2. The minified result appears immediately with the saving shown. 3. Toggle comment removal if you need comments kept. 4. Check the notes for anything that was preserved rather than collapsed. 5. Click Copy to take the output.

Common Mistakes

Treating HTML as a flat string and stripping all whitespace. It joins words together between inline elements and destroys the contents of pre and textarea.
Minifying after a templating system has inserted comment markers. Some frameworks use comments as functional placeholders, so strip them before those markers exist, not after.
Expecting the raw saving to translate into bandwidth. Gzip and brotli already remove most whitespace redundancy, so the real-world gain on a compressed response is much smaller.
Minifying the source files you edit. Keep the readable version as the source of truth and minify as a build step, or the next person to maintain it inherits an unreadable file.
Assuming minified means obfuscated. Every tag, attribute and string is still there in plain sight — this makes the file smaller, not private.

Frequently Asked Questions

Why is whitespace inside a tag not always safe to remove?

What happens to content inside pre and textarea?

How much smaller should I expect the output to be?

Should I minify HTML at all if I have compression enabled?

Are comments always safe to strip?

Does this change how my page renders?