Why Generic HTML Minifiers Break Email Templates

If you’ve ever run an email template through a generic HTML minifier (the kind built for web pages) and ended up with a broken layout in Outlook, you’ve hit one of the most common pitfalls in email development. The problem isn’t your template. It’s the tool.

What generic minifiers are built for

Tools like HTMLMinifier, Terser, and most online minifiers are designed to optimize HTML for browsers. They’re excellent at what they do: stripping whitespace, removing redundant attributes, collapsing boolean attributes, and eliminating comments: all things that shave bytes off a web page load.

But email clients are not browsers. And the assumptions baked into generic minifiers actively work against the things email templates rely on.

The Outlook conditional comment problem

The most damaging behavior is comment stripping. Generic minifiers remove HTML comments by default, since comments serve no purpose in a rendered web page. In email, they’re critical.

Outlook on Windows, which still accounts for a significant share of business email opens, uses a proprietary rendering engine based on Microsoft Word. It doesn’t support many modern CSS properties. The standard fix is to wrap Outlook-specific HTML in conditional comments:

<!--[if mso]>
<table width="600" cellpadding="0" cellspacing="0"><tr><td>
<![endif]-->
<div class="container">...</div>
<!--[if mso]>
</td></tr></table>
<![endif]-->

These comments tell Outlook to render the table-based fallback while other email clients ignore them entirely. A generic minifier that strips comments will silently delete this markup. Your email will look fine in Gmail and Apple Mail, and completely broken in Outlook, with no obvious indication of why.

MSO-specific attributes get stripped

Generic minifiers also strip attributes they consider non-standard or redundant, including mso-* style properties that only Outlook understands. Rules like mso-line-height-rule: exactly and mso-padding-alt exist specifically to override Outlook’s Word rendering behavior. Stripping them causes layout shifts, broken spacing, and font rendering issues that only appear in Outlook clients.

Whitespace rules differ in email

In web HTML, collapsing multiple spaces to one and removing whitespace between inline elements is safe. In email, it can affect rendering in older email clients and certain mobile clients that handle inline-block spacing differently than modern browsers. Email-safe minification preserves meaningful whitespace while still reducing file size.

The 102KB Gmail clipping threshold

Gmail clips any email that exceeds 102KB of HTML at the point of rendering, replacing the rest of the email with a “View entire message” link. This cuts off your unsubscribe link, your footer, and often part of your content, which is a deliverability risk.

Generic minifiers can help with file size, but they have no concept of this threshold or how to prioritize which content to preserve. An email-aware minifier knows what matters.

What to use instead

An email-specific minifier handles all of this correctly. SendReady’s HTML Minifier preserves Outlook conditional comments and MSO attributes by default, applies whitespace rules appropriate for email clients, and gives you a byte count so you can see exactly where you stand relative to Gmail’s 102KB limit.

Run it after your CSS inliner, before you upload to your ESP. You get smaller files without the breakage.

Related tools

• CSS Inliner: Inline your styles before minifying for full client compatibility.
• Spam Word Scanner: Check your copy for deliverability-killing phrases.