Exact UTF-8 bytes in the pasted or loaded HTML source.
All tools
UTF-8 / MIME / TRANSFER ENCODING / CLIPPINGCount the bytes.
Count the bytes.
Keep the message whole.
Separate HTML clipping pressure from transmission weight, attachment overhead, and remote assets—then fix the source with the biggest payoff.
- Exact UTF-8 source bytes
- Encoding-aware wire ledger
- Conservative cleanup
HTML SOURCE10.98 KB10.8% of the declared clipping-review threshold
HEADROOM AVAILABLE
The HTML has room before the declared review line.
Decoded HTML, transfer-encoded bodies, MIME attachments, and remote image downloads answer different questions. Preserve the representation and byte basis with every result.
Threshold headroom91.02 KBUTF-8 source bytes versus the configurable review line.
Quoted-printable HTML plus plain text.
Headers, bodies, structure, and encoded attachments.
1 remote image × declared average; not message bytes.
Transmission ledger
Estimated final wire representationEncoded HTML11.67 KB+6.3% versus decoded source
Encoded plain text168 B162 decoded bytes
Attachments on wire0 B0 B raw across 0 part(s)
Headers + structure2.76 KBDeclared inputs plus attachment part wrappers
Body encoding and MIME structure add transmission overhead.
1.33× sourceGmail clipping pressure and SMTP/MIME transmission weight are different measurements. Attachments and remote images do not simply add to decoded HTML source bytes.
Clipping-pressure model
Configurable operational review line10.98 KB
0 BReview line: 102.00 KB
The default 102 KB value reflects widely observed Gmail behavior, not a published universal clipping contract. Threading, provider transformations, and Gmail behavior can change the rendered result. Test the final delivered message.
Source evidence
Overlapping evidence categoriesEvidenceCountBytesShare of HTMLInterpretationAction
Ordinary comments11.55 KB14.1%Direct source weightRemove after build
Conditional comments2115 B1.0%Often supports OutlookPreserve and test
Inline style attributes734.67 KB42.5%May repeat by designReview repetition
Style blocks1136 B1.2%Client support variesRetain required rules
Embedded data URIs00 B0.0%Lives inside HTMLNone found
Remote image tags1159 B1.4%Markup only in messageOptimize hosted files
Review repeated inline declarations has the largest estimated direct opportunity at 4.02 KB.
Size findings and boundaries
5 findingsHTML source has an exact UTF-8 measurement. The current source contains 11,240 bytes across 11,240 JavaScript string units.
HTML has substantial declared threshold headroom. Current source leaves 91.02 KB before the review line. This does not replace final-client testing.
A plain-text alternative is represented. It contributes 162 B decoded and 168 B estimated encoded bytes.
Ordinary comments create a direct cleanup opportunity. Removing non-conditional comments would save about 1.55 KB without counting whitespace changes.
Remote asset cost is separate from message size. At the declared average, 1 remote images could request about 140.00 KB after display. Actual caching, blocking, formats, and responsive selection vary.
EXPORT THE BYTE BASIS
Keep decoded, encoded, MIME, and remote-asset measurements separate.
The handoff records source evidence, assumptions, potential savings, and the distinction between a clipping-risk model and actual delivered-client behavior.
Read the full agent guideTHE SIZE CONTRACT
One email has several defensible sizes.
Decoded HTML bytes help assess clipping pressure. Transfer-encoded bodies and MIME structure determine transmission weight. Attachments expand under base64. Remote images load later and do not belong in the raw message total.
Name the representation before reporting a number, and inspect the provider's final compiled source before treating a template estimate as production evidence.
- 01Compile
Measure the final provider-produced HTML, not only the editor template.
- 02Encode
Account for quoted-printable, base64, line wrapping, MIME boundaries, and attachment expansion.
- 03Separate
Keep remote image downloads outside message-wire and decoded-HTML totals.
- 04Reduce
Remove safe comments and bloat, then verify rendering, accessibility, tracking, and conditional code.
- 05Deliver
Send the final artifact to real clients and inspect clipping, links, and source after transformations.
BYTE QUESTIONS
Which size should an email team report?
Report the representation that matches the decision: decoded HTML for clipping review, encoded MIME for transport, and remote assets for post-open download cost.
What causes Gmail clipping?+
Large message source is a common trigger, but Gmail does not publish a universal clipping contract. The tool uses a configurable operational review line and requires a final delivered-message test.
Does an attachment count toward HTML clipping size?+
Not as decoded HTML source. Attachments materially increase MIME wire size because binary data is normally base64 encoded, but clipping pressure and total transmission weight are separate ledgers.
Do hosted images count toward email size?+
Their URLs and markup count in HTML. The image files normally load remotely after open, so their transfer cost is shown separately. Data-URI images are embedded in the source and do increase HTML bytes.
Why is base64 larger than the source?+
Base64 converts each three input bytes into four characters and MIME adds line breaks. This expansion is expected and differs from the decoded content size.
Is the cleaned HTML safe to send immediately?+
No. It conservatively removes ordinary comments and whitespace between tags while preserving conditional comments, but every changed artifact still needs rendering, accessibility, link, and final-build tests.
Should I minify email HTML?+
Minification can reduce bytes, but aggressive rewriting can alter text spacing, conditional comments, template syntax, or rendering. Optimize the compiled output carefully and validate the exact delivered artifact.