Free tool

Email HTML size checker

Last reviewed 18 September 2026

This tool measures the size of an email in bytes as UTF-8, which is what a mailbox provider counts, and compares it against the 102,400-byte point at which Gmail stops rendering a message and replaces the rest with a "View entire message" link. It also counts images, links and words, and reports whether the HTML uses flexbox or CSS grid, neither of which Outlook on Windows understands. The HTML is parsed in your browser and is never sent anywhere.

Paste the HTML of an email and find out whether Gmail will cut it in half, how heavy it really is in bytes, and whether anything in it depends on layout an email client will not render.

It is parsed in this page. Nothing is uploaded, and there is no request to send it in.

Paste your email above to see its size in bytes, how close it is to being clipped, and what is in it.

How this tool works

What clipping is, and the number it happens at

When the HTML part of a message is larger than a certain size, Gmail stops rendering it part-way through and appends a link reading "View entire message". Everything after the cut is still delivered and still there; it is simply not on screen, and the reader has to take an extra deliberate action to see it. The measured threshold has sat at 102,400 bytes for years — that is 102 KB counted in thousand-byte kilobytes, which is where the familiar "102 KB" figure comes from. Gmail does not document it, so treat it as an observed constant rather than a promise, and leave yourself room.

The reason to care is not aesthetic. The things that live at the bottom of an email are the unsubscribe link, the postal address and the sender identification — the parts that have to be reachable, in some jurisdictions as a matter of law and in every jurisdiction as a matter of not being reported as spam. A clipped message hides exactly those. A reader who wants out and cannot find the link presses the button that tells their provider you are a spammer instead, and that button costs you far more than the one you were trying to avoid.

Clipping is also a duplicate-content signal for the quoted thread in a long reply chain, which is why the feature exists at all. For a course email it is almost always a sign that something has gone wrong upstream: inline styles duplicated on every cell, a base64-encoded image pasted into the body, or an export from a design tool that shipped its whole stylesheet.

Why bytes rather than characters, and why UTF-8

Size limits are counted in bytes, and a character is not a byte. Encoded as UTF-8, plain Latin letters take one byte each, an em dash or a curly quote takes three, and an emoji takes four. So a message whose length reads as 80,000 characters in an editor can be well over 102,400 bytes on the wire, and one full of typographic punctuation gets there faster than you would guess. This tool encodes the HTML you paste as UTF-8 and counts the result, which is the same number a provider counts.

Two things inflate an email far beyond what the writing in it suggests. The first is base64: an image embedded directly in the HTML rather than linked grows by about a third over its file size, so a single modest 90 KB photograph pasted inline has already spent more than the entire budget. Link to images instead and let the client fetch them. The second is inline CSS on every element, which is the correct way to style email and also a duplication machine: a style string repeated across two hundred table cells is most of a clipped message.

The word count this tool reports is taken from the text after scripts, styles, comments and tags have been stripped, so it is the number of words a reader actually meets. It is worth watching next to the byte count: a lesson of four hundred words inside 90 KB of HTML is a lesson wearing about eighty kilobytes of scaffolding.

Flexbox and grid in email, and what to use instead

Outlook on Windows renders HTML through Microsoft Word rather than a browser engine. Word does not implement flexbox or CSS grid, and its handling of floats, positioning and modern selectors is limited enough that the safe assumption is that none of it works. So a layout built with `display: flex` collapses into a single stack of full-width blocks in one of the most common desktop clients in professional use, and the person who sees it has no idea that is not what you sent.

This tool flags the declarations rather than guessing at intent: display set to flex, inline-flex, grid or inline-grid, along with grid-template-columns and flex-direction. A hit is not automatically a defect. If the layout degrades gracefully — one column stacked in the order you wrote it — then flex in a supporting client is a perfectly reasonable enhancement, and Apple Mail and Gmail will honour it. A hit is a defect when the design only makes sense side by side.

The reliable alternative is the old one: nested tables for structure, widths in attributes as well as CSS, and a single column under about 600 pixels. For a course email the better answer is usually to stop needing layout at all. A lesson is prose, a heading and a link; it does not need columns, and an email that is one column of text in a sensible typeface renders identically everywhere and is the format readers say they prefer.

Common questions

What is the Gmail clipping limit?

Around 102,400 bytes of message content, after which Gmail stops rendering and shows a "View entire message" link. The figure is observed rather than documented, so aim well under it: keeping an email below about 60 KB leaves room for whatever a sending platform adds on the way out.

Does a large email land in spam?

Size is not a spam signal in itself. The harm is indirect and real: a clipped message hides the unsubscribe link and the postal address at the bottom, so readers who want out report the message instead, and complaint rate is a signal that matters a great deal.

Can I use flexbox or CSS grid in an email?

Only as an enhancement. Outlook on Windows renders through the Word engine, which supports neither, so any layout that depends on them collapses to a single stack there. Build for one column, and let clients that support modern CSS improve on it if you want.

How many images should a lesson in an email course have?

As few as the teaching needs, and none that the teaching depends on. Remote images are blocked by default in some clients and stripped by some gateways, so every image needs alt text and the lesson has to read completely with all of them switched off.

More tools

  • Email subject line tester

    Paste a subject line and a preheader to see the character count, where each inbox cuts it off, and the five flags that get a course email ignored.

  • Email course outline generator

    Say what you teach, who it is for and how many days you want, and get a day-by-day outline with a subject line for each email. Rule-based, with no AI.

  • DMARC, SPF and DKIM checker

    Enter a domain to read its SPF and DMARC records, and a selector to read a DKIM key, with a verdict on each of the things that matter for bulk mail.

All four are on the tools index , and the longer writing about email courses is in the guides . What this site itself does is on the home page.

Elsewhere on this site

The rest of this site comes at the same subject from other directions: guides on the format itself, a tool for one job each, a page for each kind of work, and what to check when choosing software.

Thinking of writing one of these?

5dayemail hosts a five-to-ten day email course: you write it once, and everyone who joins your list gets one email a day, in order, starting from the day they confirm.

Accounts are opened a few at a time rather than by signing up. Leave your address and you will be written to when the next ones open.

One message, when there is room. No course emails, no newsletter, and the address is not passed on. Ask and it is deleted; what is kept, and for how long, is in the privacy policy.