Will removing optional closing tags break anything in older browsers?
The HTML5 specification explicitly lists tags with optional end tags — </li>, </dt>, </dd>, </p>, </td>, </th>, </tr>, </thead>, </tbody>, </tfoot>, and a few others. Modern browsers including IE 11 and every current engine handle their omission correctly because the parser infers them from context. Where you can run into trouble is with older HTML email clients like Outlook 2016, which uses the Word rendering engine rather than a browser engine and can misparse omitted </td> or </tr> tags. For email templates, keep closing tags even if you strip whitespace and comments.
Does minifying HTML actually matter for performance when most servers already use gzip or Brotli?
Compression algorithms like gzip and Brotli work on repetition, so whitespace-heavy HTML compresses extremely well — a file that's 40% whitespace often shrinks by 80% or more over the wire. Minifying first and then compressing yields diminishing returns compared to compression alone. Where minification still pays off is reducing the uncompressed payload that the browser parses and builds the DOM from, and in reducing the size of inline HTML in environments where transport compression isn't applied, such as some HTML email relay pipelines or embedded webview content.
Can this handle HTML with embedded <script> or <style> blocks without corrupting them?
Whitespace inside <script> and <style> blocks is syntactically significant to the JavaScript and CSS parsers, so a correct HTML minifier preserves those blocks' internal content or delegates to a JS/CSS minifier separately. This tool operates at the HTML level — it won't compress your inline JavaScript or CSS, but it also won't corrupt them by collapsing whitespace inside those tags. If you need inline JS and CSS compressed too, run the HTML through a full pipeline tool like html-minifier-terser with its js and css minification options enabled.
Why is my minified output larger than I expected after I paste it back into a file?
The most common cause is character encoding. If your original file was saved as UTF-8 with a BOM (byte order mark), the three-byte BOM prefix is invisible in most editors but counts toward file size. A second cause is that whitespace in the original may already have been minimal — a file generated by a build tool often has very little redundant whitespace left to remove. Copy the minified output into your browser's DevTools console and check its byte length with new TextEncoder().encode(str).byteLength to confirm the actual byte count independent of editor display.
How is this different from running html-minifier-terser locally via npm?
html-minifier-terser is a Node.js CLI and library with around 30 configurable options covering JS minification, CSS minification, attribute quoting, boolean attribute collapsing, and more. It's the right choice when you need reproducible minification as part of a build pipeline with version-controlled settings. This browser tool is for ad-hoc use — no installation, no config file, no terminal. The trade-off is fewer options and no ability to process multiple files in a batch. For one file you're about to paste into a deploy form, the browser tool is faster; for anything automated or repeatable, reach for the CLI.