Gmail clips an HTML message that exceeds roughly 102 KB on the desktop web client. The clip is destructive: the visible body ends at the truncation point, everything after it is replaced with a “[Message clipped] View entire message” link, and the recipient has to click that link and load the full source in a new tab before any content, CTA, or tracking pixel below the cut can render or fire. Almost nobody clicks it. If your CTA or open pixel sits below the cut, they simply do not exist for that opening. The 102 KB budget is the byte length of the message body Gmail is asked to render – not the file size of the delivered .eml – so it includes every character of markup, every inline style repetition, every base64-encoded image, every HTML comment, every tracking parameter on every href, and every <style> block. Templates that look fine in a browser preview clip because the browser rendered a decoded document while Gmail measures the raw source.
Byte weight is the UTF-8 length of the pasted HTML — the same number Gmail measures. This plugin serves no upload endpoint; the HTML never crosses the network. Component boundaries are inferred with regex, so the breakdown is an estimate for prioritising cuts, not an exact tokeniser output.
How the analyzer counts
The tool measures the UTF-8 byte length of exactly the string you paste – the same measurement Gmail runs. It then attributes those bytes across seven buckets and reports the total against the 102 KB desktop-Gmail ceiling. The verdict banner switches at three thresholds: under 90% of budget is a clean pass, 90-100% is a warning that a follow-up section edit is likely to push you over, and 100% or more is a clipping verdict with a call to trim.
The breakdown categories:
- HTML markup (residual) – everything not otherwise attributed. On a normal template this dominates and is not itself a problem; on a base64-heavy template it collapses to almost nothing.
- CSS in
<style>blocks – the content between<style>...</style>tags. Email resets, media queries, Outlook-only rules. style="…"attributes – inline styles on individual elements. The email-CSS standard, but repetition across rows and buttons multiplies quickly.- Base64 image payloads – the base64 characters inside
data:image/...;base64,...URLs. Base64 inflates the underlying binary by about 33%; a 50 KB image becomes ~67 KB of message weight when inlined. - Tracking pixels –
<img>tags detected as 1×1 opens or as bearing an ESP tracking URL fingerprint (/open/,/track/,mkt_tok=,utm_medium=email). - HTML comments – content between
<!-- -->. Editor scaffolding, section anchors, tracking notes. Outlook-conditional wrappers (<!--[if mso]>...<![endif]-->) look like comments to the analyzer but Outlook depends on them to render its fallback markup; strip them and Outlook loses those overrides. - Preheader (hidden text) – a hidden block near the top of
<body>withdisplay:noneormso-hide:all. Usually a one-liner; oversized ones are legacy pad-out characters that inbox clients no longer honour anyway.
Categories are inferred with regex on the raw HTML, so a template that base64-encodes an image inside a hidden preheader will count the payload in two categories. The breakdown is an estimate for prioritising cuts, not an exact tokeniser output – that’s what the “suggested cuts” list is for.
Why templates that pass in preview still clip
The clip is on the encoded source, not the rendered document, so any of these can push a template over the line without changing what a preview shows:
- Duplicated tracking pixels stacked by nested partials. Three open pixels are worse than one, and every export of the master template adds one; the analyzer counts each.
- Personalisation tokens that expand at merge time. If a name field expands to a 40-character full name and the template references it in a dozen places, that’s an extra 500 bytes per recipient that the preview never showed.
- MSO-conditional Outlook fallbacks embedded per row. Each row’s
<!--[if mso]>...<![endif]-->wrapper survives to Gmail even though Gmail ignores its contents. The bytes still count. - Base64-inlined hero images or logos to work around image-loading being off by default. The bytes are inside the source, so Gmail measures them; hosting the image externally at your ESP or CDN is the standard fix.
- Reset stylesheets copied wholesale from an old master template and never trimmed. A 12 KB reset that half the template does not use is 12 KB of budget you could spend on copy.
The mobile floor is lower
The 102 KB ceiling is Gmail’s desktop web client. The mobile Gmail app clips around 75 KB, and the iOS Gmail app has been observed clipping as low as 20 KB in some configurations, applied inconsistently. The analyzer reports the desktop verdict because that’s the widely-cited planning number; if your audience skews mobile, treat the desktop budget as a ceiling to stay well under, not a target to hit.
What the analyzer does not do
- No image fetching. External
<img src="https://...">URLs are counted as markup; the referenced image is not downloaded and does not count toward the budget (which matches how Gmail measures). - No template rendering. Merge tags like
{{first_name}}are counted at their literal source length, not at post-merge length. If your merged bodies are noticeably larger than the template, run the analyzer on a rendered sample. - No spam-score or CSS-support analysis. This is a weight analyzer, not a rendering analyzer. Use Litmus or Email on Acid for a rendering pass.
Related email-render tools
- If deliverability is failing at the same time as clipping – the message ends up in spam and the visible portion above the fold happens to be a footer notice – the header auth visualizer reads SPF, DKIM, DMARC, and ARC verdicts out of a copy of the raw headers.
- If you are not sure who is sending as your domain in the first place, the DMARC XML reader parses an aggregate report in your browser and returns a plain-English source list.
- If the template lives in a WordPress site and the mailer is misconfigured (so nothing is going out at all), the WP Mail config generator emits provider-specific SMTP snippets for the five common delivery methods.
