Free · Fast · Privacy-first

Minify HTML for Email Templates

Email HTML operates under stricter size constraints than web HTML.

⚡

Reduces email template HTML size

🔒

Preserves inline styles required for email

✨

Removes comments from email HTML

⚡

Free with no account required

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this HTML Minify to your website

Drop the HTML Minify into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/html/html-minify?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Minify by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/html/html-minify?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Minify by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Why Email HTML Size Matters More Than Web HTML Size

Email HTML exists in a more constrained and less forgiving environment than web HTML. Gmail clips email messages at 102KB with a "Message clipped" label and a link to view the full message. This is not a soft guideline but a hard cutoff: everything below the clip point is completely invisible to the reader unless they actively click to expand the message. Most readers do not expand clipped messages, which means CTAs, product recommendations, and discount codes placed near the end of long templates are simply never seen by Gmail users. Email HTML tends to run larger than equivalent web pages for structural reasons. CSS must be inlined into style attributes on every element because external stylesheets are ignored by most email clients. Tables are used for layout because flexbox and grid have poor support in Outlook and other clients. Media queries must be embedded in a head style block rather than referenced as external files. All of these constraints produce more verbose markup than a typical web page for the same visual design, making whitespace and comment removal more impactful in email than in web HTML.

The minification approach for email HTML requires more caution than for web HTML, and this distinction matters in practice. Modern web browsers implement forgiving HTML5 parsers that recover gracefully from omitted optional closing tags, mismatched case, and unusual whitespace. Microsoft Outlook uses Microsoft Word's rendering engine, which is significantly less forgiving. Optional closing tag removal that produces valid, renderable web HTML can cause Outlook to misinterpret the document structure and produce broken table layouts or missing content sections. A conservative email minifier applies only the safest operations: whitespace removal between block elements, comment stripping, and collapsing of multiple spaces. FixTools applies this conservative default approach, which is appropriate for email and avoids the structural risks of more aggressive optimisations.

For the most effective email minification workflow, perform CSS inlining before minification rather than after. CSS inlining tools such as Juice, Premailer, or the inliner built into your email service provider convert external and head-block CSS into inline style attributes on every element. This step itself adds significant byte count because style rules are repeated on each element rather than being declared once. Running HTML minification after CSS inlining removes the whitespace introduced by the inliner and produces a net reduction that is larger than minifying before inlining. After minification, test the output in your target email clients before sending to your full list.

Conditional comment preservation deserves its own attention in any email minification workflow because email is the one context in 2026 where these legacy comment blocks still earn their place in the markup. The MSO conditional comment syntax targets specific Outlook versions and is used to deliver VML fallback graphics for hero banners, bulletproof button shapes that survive the Word renderer, and Outlook-specific table widths that fix the well-known 120 percent zoom bug. Stripping these comments to save bytes can break the Outlook rendering of an otherwise pixel-perfect email. The conservative approach is to configure the minifier to preserve any comment that begins with the MSO pragma while removing every other comment in the document, including developer notes, generator attribution from the email builder, and section markers. This delivers the bulk of the byte saving without surrendering Outlook compatibility for the subscribers who still read mail in older Outlook versions.

Litmus: Email client market share Campaign Monitor: HTML email guide

How to use this tool

💡

Paste your email HTML template and minify. The output removes unnecessary whitespace and comments while preserving all inline styles and table structure email requires.

How It Works

Step-by-step guide to minify html for email templates:

1
Validate email HTML first
Run your email HTML through an email validator such as the one at validator.w3.org or a dedicated email validation tool to identify and fix any structural errors before minification. Fixing markup issues in the formatted version is far easier than debugging them in minified output.
2
Paste and minify
Paste the email HTML into the FixTools HTML Minifier input panel and click Minify. The tool applies conservative minification appropriate for email, stripping whitespace and comments while preserving inline styles, table structure, and conditional comment blocks.
3
Check the minified size
Read the minified byte count in the FixTools interface. Confirm the minified template is under your ESP's upload size limit and under Gmail's 102KB clip threshold. If it remains over the threshold, review the template for content sections that could be reduced before attempting further minification.
4
Test before sending
Send the minified template to test addresses in Gmail, Outlook, and Apple Mail, or use Litmus or Email on Acid to render across all clients simultaneously. Confirm visual output is correct in all target clients before deploying the template to your full subscriber list.

Real-world examples

Common situations where this approach makes a real difference:

Reducing an email template close to Gmail's 102KB clip limit

A promotional email template for a seasonal campaign is measuring 98KB after CSS inlining by the ESP. With Gmail's 102KB clip threshold only 4KB away, a minor content addition for the next send could push it over the limit and hide the final CTA section from Gmail users. Running the template through FixTools removes 9KB of whitespace and comments, bringing it to 89KB. The buffer below the clip threshold is now comfortable, and the design team can safely add content in future sends without risking clipping.

Compressing email templates before loading into an ESP

Klaviyo enforces a 100KB template size limit. A detailed product announcement email with multiple product blocks, an editorial section, and a discount code section measures 104KB before minification. The marketing team uses FixTools to strip 12KB of whitespace and comments, reducing the template to 92KB and clearing Klaviyo's upload limit. The minification process takes under two minutes and requires no code changes or content removal.

When to use this guide

Use this before sending an HTML email campaign to reduce template size, improve delivery rates, and avoid email client clipping from large HTML payloads.

Pro tips

Get better results with these expert suggestions:

Inline CSS before minifying

Use a CSS inlining tool such as Juice, Premailer, or your ESP's built-in inliner to convert all style declarations to inline style attributes before running the HTML through FixTools. CSS inlining expands the file with repeated style values on every element, and minification then removes all the surrounding whitespace from those expanded rules. Running minification before inlining misses the whitespace introduced by the inliner, producing a larger final output than the correct sequence.

Check email client rendering after minification

Use Litmus or Email on Acid to test your minified email template across the full range of clients, including Outlook 2016, 2019, and 365, Gmail on desktop and mobile, Apple Mail, Samsung Mail, and Yahoo Mail, before sending to your list. These services render your template in dozens of clients simultaneously, catching Outlook-specific whitespace rendering issues, such as extra spacing between table cells or misaligned layouts, that appear only in Outlook's Word-based renderer and are invisible in a standard web browser preview.

Remove conditional comments for modern-only sends

If your subscriber list analysis shows negligible usage of Outlook 2007, 2010, or 2013, the conditional comment blocks in your template that target those versions, typically MSO-specific VML code for background images and button shapes, can be safely removed. Each conditional comment block averages 500 bytes to 2KB in a typical template. Stripping them during minification can produce meaningful additional size reduction for templates that include several such blocks.

Monitor clipping rates in your ESP

After deploying minified templates to a live campaign, check your ESP analytics dashboard for Gmail-specific open rates and click-through rates in the first send. If Gmail metrics drop notably compared to prior sends with similar content, investigate whether the template is still being clipped. ESPs like Klaviyo, Mailchimp, and HubSpot provide email client breakdowns that show Gmail open counts. A significant drop in Gmail opens after a size change is a signal worth investigating before the next send.

Gmail clips emails over 102KB

Gmail clips email messages at 102KB with a "Message clipped" notice. Keep your email HTML under this limit, minification helps if you are close to the threshold.

Email HTML minification is more conservative

Email minifiers are more conservative than web minifiers. Optional closing tags that are safe for browsers may cause problems in Outlook. FixTools handles this conservatively.

Test after minifying

Always test your minified email HTML in the major email clients (Gmail, Outlook, Apple Mail) before sending. Minification can occasionally reveal rendering issues caused by whitespace-dependent inline-block layouts.

FAQ

Frequently asked questions

It can, particularly in Outlook. Outlook uses Microsoft Word's rendering engine rather than a standard HTML parser, and this engine is sensitive to certain structural changes that modern browsers handle gracefully. Specifically, optional closing tag removal and aggressive whitespace collapsing around inline elements can produce unexpected spacing or layout shifts in Outlook. FixTools applies conservative minification settings by default to avoid these issues, but always test in Outlook after minifying email HTML before sending to your list.

After CSS inlining. The correct sequence is: write your CSS in a head style block or external file, run the template through a CSS inliner to convert all styles to inline attributes, then run the inlined result through FixTools to remove whitespace. CSS inlining adds substantial whitespace as each element receives a style attribute, and minification removes this efficiently. Minifying before inlining and then inlining introduces new whitespace that is not removed, producing a larger final output.

Gmail clips email messages when the HTML payload exceeds 102KB. Content below the clip line is hidden behind a "Message clipped" notice and a link to expand. Click-through rates on content below the clip are dramatically lower than on visible content. HTML minification removes whitespace and comments, which in a typical inlined email template account for 8 to 15KB of the total size. For templates hovering near the 102KB threshold, this removal is often sufficient to keep the full template visible in Gmail without removing any actual content or changing the design.

Smaller HTML email size has a modest positive effect on deliverability. Some spam filters score large HTML payloads negatively as a signal that the message may contain hidden content or tracking mechanisms. Keeping email HTML under 100KB is a recommended best practice in most email deliverability guides. Minification is the lowest-effort way to achieve this size reduction without removing content. The impact on deliverability is secondary to factors like sender reputation and content quality, but it is one of several hygiene improvements worth making.

Conditional comments targeting specific Outlook versions should be preserved if those versions are in your target audience. VML blocks used for Outlook-compatible background images or button rendering are sensitive to whitespace changes and should be treated carefully. Standard whitespace removal around regular HTML block elements is safe for all email content. FixTools handles conditional comments conservatively and preserves VML block structure, but always verify rendering in Outlook after minification when your template includes these elements.

Rarely. Email HTML and web HTML serve different rendering contexts and are typically distinct documents with fundamentally different structural approaches. Email HTML uses table-based layouts for Outlook compatibility, inline CSS because email clients ignore external stylesheets, and specific VML and conditional comment structures for Outlook. Web HTML uses div-based layouts with flexbox or grid, external stylesheets, and relies on modern browser parsing. These documents should be maintained separately and minified independently for their respective contexts.

Use Litmus or Email on Acid to preview your minified template simultaneously across Gmail, Outlook 2016, 2019, and 365, Apple Mail, Samsung Mail, Yahoo Mail, and major mobile clients. These services render your HTML in actual email clients and return screenshots, which takes about 60 seconds. Alternatively, send test emails from your ESP to seed addresses covering your primary target clients. Always complete this testing step before sending to your full subscriber list, as issues caught in testing cost nothing to fix, while issues discovered after sending affect every recipient.

No. Preheader text is HTML body content, typically a short sentence placed in a span at the top of the email body, styled with display:none or zero height to hide it visually while allowing inbox preview text algorithms to read it. The HTML minifier preserves all text node content and all style attributes on elements, including visibility-hiding styles. Your preheader span and its text content are fully preserved, and the inbox preview text that email clients derive from it is completely unaffected by the minification process.

Outlook adds invisible whitespace between table rows when the surrounding HTML contains certain whitespace patterns that the Word renderer interprets as block-level breaks. The fix is to apply mso-line-height-rule and mso-table-lspace inline styles to the affected table elements rather than restoring whitespace in the source. Specifically, set mso-line-height-rule:exactly on text containers and mso-table-lspace:0 plus mso-table-rspace:0 on table tags to suppress the Word renderer spacing behaviour. Re-minify after adding these styles and the gaps will not return. Outlook-specific styles like these are exactly the kind of email-engineering trick that survives minification because they are inline attribute values, which the minifier preserves byte for byte.

No. Tracking pixels are img elements with a one-by-one pixel source URL pointing to your ESP analytics endpoint, and they are preserved exactly by the minifier including the src attribute, alt attribute, and any width or height attributes. The minifier removes only whitespace and comments around the pixel element, never the element itself. Open rate measurement continues to work normally after minification because the pixel still fires when the recipient renders the email and downloads the image. If you notice an open rate drop after deploying a minified template, investigate other factors like image blocking settings, send time changes, or audience composition rather than blaming the minification.