# Email Size Checker and Gmail Clipping Analyzer

> Measure decoded HTML source, transfer-encoded bodies, MIME and attachment wire weight, remote image cost, clipping pressure, and practical byte-reduction opportunities without collapsing several different representations into one misleading number.

- **Canonical page:** [https://emailbump.com/tools/email-size-checker](https://emailbump.com/tools/email-size-checker)
- **Interactive tool:** [Open the email size checker](https://emailbump.com/tools/email-size-checker)
- **Primary clipping input:** compiled HTML measured as UTF-8 bytes
- **Wire model:** headers, multipart structure, encoded HTML, encoded plain text, and base64 attachments
- **Remote asset model:** image count multiplied by a declared average asset weight
- **Exports:** size brief, conservatively cleaned HTML, savings CSV, and analysis JSON
- **Privacy:** pasted and loaded source stays in the browser

## What this tool answers

The checker answers:

1. How many UTF-8 bytes are in the current HTML source?
2. How much of a declared clipping-review threshold does that source use?
3. How much headroom remains?
4. How large are the HTML and plain-text parts after the selected content-transfer encoding?
5. How much can binary attachments expand under base64?
6. What is the estimated full MIME wire size?
7. How many remote image tags are present?
8. What post-open remote image load does the declared average imply?
9. How many bytes appear in ordinary comments, conditional comments, style attributes, style blocks, and embedded data URIs?
10. Which direct or directional cleanup opportunity is largest?

It does not prove:

- that Gmail will or will not clip a message;
- that a provider will preserve the pasted source byte for byte;
- that an email will reach the inbox;
- that remote images will load;
- that aggressive minification is safe;
- or that the estimated MIME wire representation matches a provider's final message.

Inspect the final compiled and delivered source when the decision matters.

## One email has several sizes

“Email size” is ambiguous.

At least four representations matter:

1. **Decoded HTML source bytes** — useful for HTML-source and clipping-pressure review.
2. **Transfer-encoded text-body bytes** — useful for estimating how HTML and plain text travel in MIME.
3. **Full MIME wire bytes** — useful for transmission, storage, provider, and attachment analysis.
4. **Remote asset bytes** — useful for estimating post-open image download cost.

These are related but not interchangeable.

A hosted image contributes a URL and markup to the HTML source. The image file normally loads separately after open.

An attachment is normally a separate MIME part. Its base64 representation increases wire size but is not decoded HTML source.

A data-URI image embeds encoded asset data directly in markup and therefore increases HTML source bytes.

Always attach the representation to the number.

## UTF-8 source measurement

The tool measures the pasted or loaded HTML with a browser `TextEncoder`.

```text
HTML source bytes = length of UTF-8 encoded HTML
```

This differs from:

- JavaScript string length;
- visible character count;
- editor file size under another character encoding;
- DOM node count;
- transfer-encoded length;
- and remote asset weight.

ASCII characters generally use one UTF-8 byte. Other characters may require multiple bytes.

The interface reports both exact UTF-8 bytes and a human-readable binary-unit display:

```text
1 KB = 1,024 bytes
1 MB = 1,024 × 1,024 bytes
```

The unit definition is explicit because some dashboards use decimal kilobytes.

## Gmail clipping review

The default review line is 102 KB because that value is widely observed in Gmail clipping discussions and email-production practice.

It is not treated as a published universal protocol limit.

The model is:

```text
threshold bytes = declared threshold KB × 1,024

threshold use = HTML source bytes / threshold bytes

headroom = threshold bytes - HTML source bytes
```

The tool uses three operational states:

- below 75%: substantial declared headroom;
- from 75% to below 100%: review buffer;
- at or above 100%: beyond the declared review line.

The 75% buffer is a product decision for visibility. It is not a Gmail standard.

Why preserve a buffer?

- an email provider may compile template syntax into more markup;
- personalization can add characters;
- tracking parameters can lengthen URLs;
- link rewriting can add bytes;
- conditional branches may expand;
- an editor may inject styles or attributes;
- and the final delivered source can differ from the template.

Threading and Gmail-side behavior can also affect what a recipient sees.

The correct final test is a delivered message produced by the actual sending path.

## Transfer encoding

MIME text parts can use content-transfer encodings such as:

- quoted-printable;
- base64;
- or an identity representation such as 8bit.

[RFC 2045](https://www.rfc-editor.org/rfc/rfc2045.html) defines MIME content-transfer encodings and the 76-character encoded-line constraint for quoted-printable and base64.

### Base64 body estimate

Base64 represents each three input bytes with four characters, then MIME adds line breaks.

The tool estimates:

```text
base64 characters = 4 × ceil(raw bytes / 3)

line breaks = floor((base64 characters - 1) / 76)

base64 wire bytes = base64 characters + (line breaks × 2)
```

Each line break is counted as CRLF, or two bytes.

Base64 expansion is expected. It does not mean the decoded content changed.

### Quoted-printable estimate

The quoted-printable estimator:

- encodes UTF-8 bytes;
- preserves safe printable ASCII where possible;
- represents other octets as an equals sign plus two hexadecimal digits;
- encodes trailing spaces and tabs;
- normalizes hard line endings to CRLF;
- and inserts soft breaks to keep encoded lines within the RFC constraint.

Quoted-printable size depends on content.

ASCII-heavy HTML may remain relatively readable and compact. Non-ASCII copy, equals signs, unsafe bytes, and long lines can increase the representation.

The estimate is useful for planning. Inspect the provider's final raw MIME source for exact evidence.

### 8bit identity estimate

The identity option counts UTF-8 bytes after line-ending normalization.

It does not assert that every transport path or provider will use 8bit unchanged.

## Plain-text alternative

A multipart/alternative email commonly contains both:

- a `text/plain` part;
- and a `text/html` part.

The tool measures and encodes both.

An empty plain-text input triggers a finding because email quality is not only a byte problem.

A useful plain-text alternative should preserve:

- message meaning;
- important links;
- the primary action;
- preference and unsubscribe paths where applicable;
- and readable structure.

Do not delete the alternative merely to reduce size without understanding the accessibility, client, and operational consequences.

## MIME structure and headers

The tool accepts declared byte estimates for:

- message headers;
- multipart boundaries and structural MIME fields;
- and attachment part wrappers.

The estimated envelope portion is:

```text
envelope bytes =
  declared message headers
  + declared MIME structure
  + attachment part wrappers
```

The full estimate is:

```text
estimated MIME wire bytes =
  headers
  + MIME structure
  + encoded HTML
  + encoded plain text
  + encoded attachment payload
  + attachment part wrappers
```

Real headers vary with:

- authentication;
- routing;
- provider metadata;
- list headers;
- message identifiers;
- threading;
- trace fields;
- and downstream hops.

Use a raw delivered message when header precision matters.

## Attachment expansion

Binary attachments are generally represented with base64.

The raw attachment total is:

```text
raw attachment bytes = declared attachment KB × 1,024
```

The tool applies the same base64 quantum and 76-character line-wrap estimate, then adds 550 bytes per declared attachment as a transparent wrapper approximation.

The wrapper estimate covers directional overhead such as:

- content type;
- transfer encoding;
- disposition;
- filename parameters;
- boundary delimiters;
- and line breaks.

Providers can produce different wrapper sizes.

Attachment weight does not simply add to decoded HTML clipping weight. It belongs in the MIME wire ledger.

## Remote images

The source inspector counts `img` tags whose `src` begins with `http://` or `https://`.

The remote load estimate is:

```text
remote image load =
  remote image count × declared average image KB × 1,024
```

This is deliberately a scenario, not a network trace.

Actual bytes depend on:

- client image blocking;
- proxying;
- caching;
- format negotiation;
- responsive image selection;
- device pixel density;
- CDN transformations;
- and whether the recipient opens the message.

Remote asset weight is shown separately because hosted images are not embedded MIME bytes merely because they appear visually in the email.

The URL and element markup still count in HTML.

## Data-URI assets

The analyzer searches for `src` and `background` attributes containing `data:` URIs.

Those references live inside the HTML source.

They can create large clipping pressure because encoded asset content becomes markup bytes.

The estimated cleanup opportunity uses the full matched attribute size. Replacing it with a hosted URL would still require some source bytes, so the reported opportunity is directional rather than guaranteed savings.

Client support and security handling for embedded assets also vary.

## Source evidence

The evidence table reports overlapping categories.

Do not add every evidence-byte row together. A style attribute is inside HTML, and a data URI can also be inside an element attribute.

Categories include:

### Ordinary comments

Ordinary HTML comments are direct source weight.

Builder metadata, editor notes, and debugging comments can be removed from a production artifact when no downstream system depends on them.

### Conditional comments

Conditional comments often contain Microsoft Outlook-specific structure.

The tool measures them but preserves them during conservative cleanup.

Do not remove them solely because they look like comments.

### Inline style attributes

Inline CSS often repeats across rows and components.

That repetition can be intentional because email-client support for embedded styles and classes varies.

The tool estimates repeated declaration share, but labels the opportunity directional.

Changing inline CSS requires rendering tests.

### Style blocks

Style blocks can include:

- responsive media queries;
- dark-mode adaptations;
- client targeting;
- resets;
- and progressive enhancements.

Their presence is not automatically bloat.

### Remote image markup

The table reports markup bytes for matched remote `img` tags.

That evidence is separate from the estimated downloaded files.

## Conservative cleaned HTML

The “Copy cleaned HTML” action:

1. removes ordinary HTML comments;
2. preserves conditional comments beginning with `[if` or conditional end markers;
3. collapses whitespace between tags;
4. trims the result.

It does not:

- rewrite CSS;
- change URLs;
- remove data URIs;
- modify table structure;
- optimize images;
- understand every template language;
- or prove visual equivalence.

Even conservative text transformations can alter:

- spacing around inline elements;
- preformatted content;
- template delimiters;
- malformed markup recovery;
- and provider compilation behavior.

Treat the output as a candidate for testing, not a production-ready guarantee.

## Savings model

The tool creates four possible savings rows:

1. ordinary comment removal — direct;
2. inter-tag whitespace collapse — directional;
3. data-URI replacement — directional;
4. repeated inline declaration review — directional.

“Direct” means the matched bytes can be counted in the current source.

“Directional” means an alternative implementation still consumes bytes or may not be safe.

The largest opportunity is a prioritization hint.

Start with changes that:

- have clear ownership;
- do not remove required compatibility code;
- preserve accessibility;
- preserve tracking and personalization;
- and can be verified in the final compiled source.

## Common mistakes

### Counting characters instead of bytes

UTF-8 byte length can exceed character count.

### Measuring the editor template

Provider compilation can add or remove markup.

### Adding hosted image file sizes to HTML bytes

Hosted assets normally load separately.

### Ignoring attachment base64 expansion

Raw binary size is not wire size.

### Removing all comments

Conditional comments may be required for Outlook.

### Treating 102 KB as a formal universal contract

Use it as a configurable observed review line and test the delivered result.

### Aggressively minifying without rendering tests

Byte reduction can damage layout, copy spacing, conditional code, or template syntax.

### Reporting only total MIME size

That number can hide whether the decision concerns clipping, provider limits, storage, or open-time downloads.

## Invalid and edge cases

### Empty HTML

The tool cannot assess source size without source.

### Zero clipping threshold

The threshold ratio is not usable. Set a positive local review line.

### No plain text

The wire estimate remains possible, but the tool reports the missing alternative.

### Zero attachments

Attachment wire weight is zero.

### Attachment size with zero count

The base64 payload is still estimated from the declared raw total, while wrapper overhead remains zero. Reconcile the inputs before using the result operationally.

### Attachment count with zero raw size

Only wrapper overhead is modeled.

### No remote images

Remote load is zero. CSS backgrounds, video posters, external fonts, and other fetched resources are not comprehensively discovered by the simple `img src` inspection.

### Malformed HTML

The source measurement remains exact for the text. Regex-based evidence categories may be incomplete.

### Extremely large input

Browser processing remains local, but very large source can affect editor responsiveness.

## Recommended operating workflow

1. Export or inspect the final compiled provider HTML.
2. Paste or load that source.
3. Add the final plain-text alternative.
4. Select the actual content-transfer encoding when known.
5. Record realistic header and MIME structural estimates.
6. Add raw attachment total and count.
7. Set a documented clipping-review threshold.
8. Measure exact UTF-8 HTML source.
9. Review the buffer before the threshold.
10. Inspect ordinary and conditional comments separately.
11. Review data URIs and repeated inline declarations.
12. Keep hosted-image download cost separate.
13. Export the evidence and assumptions.
14. Apply the safest high-value reductions.
15. Compile the message again.
16. Re-measure the compiled artifact.
17. Send to real Gmail, Outlook, Apple Mail, and relevant client accounts.
18. Inspect clipping, source, links, accessibility, tracking, and rendering.

## Questions for a release review

- Is this the final compiled HTML?
- Which byte representation is being reported?
- Is the threshold an internal rule or an observed client behavior?
- How much can personalization and link rewriting add?
- Are any data URIs embedded?
- Are ordinary comments safe to remove?
- Which conditional comments are required for Outlook?
- Is inline CSS repetition intentional?
- Does a plain-text alternative exist?
- Are attachments necessary?
- What is the remote asset budget?
- Was the cleaned output recompiled and remeasured?
- Was the final delivered message inspected in target clients?

## Related tools and guidance

- [Email preview text generator](https://emailbump.com/tools/email-preview-text-generator.md)
- [Email accessibility checker](https://emailbump.com/tools/email-accessibility-checker.md)
- [Email color contrast checker](https://emailbump.com/tools/email-color-contrast-checker.md)
- [Email deliverability score](https://emailbump.com/tools/email-deliverability-score.md)
- [Email word counter](https://emailbump.com/tools/email-word-counter.md)
- [Email header analyzer](https://emailbump.com/tools/email-header-analyzer.md)
- [Email link checker](https://emailbump.com/tools/email-link-checker.md)
- [Transactional email definition](https://emailbump.com/glossary/transactional-email.md)
- [Email deliverability definition](https://emailbump.com/glossary/email-deliverability.md)
- [RFC 2045: MIME Part One](https://www.rfc-editor.org/rfc/rfc2045.html)