Sending a 50MB HTML file when email refuses (2026)

You build the report. Charts inlined, methodology appendix expanded, customer-quote video clips embedded as base64. The file is 47MB. You attach it to the email, hit send.

Gmail rejects with "Attachment exceeds the maximum size limit." Outlook would have done the same thing differently — silently bouncing the email back from the recipient's server. Corporate Exchange might cap at 10MB and not even attempt the send.

The size of the file isn't the bug. The wrong channel for that size is.

The actual limits

For reference:

The inbound limit matters too — even if your provider sends a 30MB attachment, the recipient's provider might reject it. The realistic ceiling for "this will reach most recipients via email" is around 15MB.

A self-contained HTML report typically lands somewhere between 200KB (lean text-only) and 5-10MB (with a few inline charts). Once embedded base64 images or video clips show up, the file size compounds quickly. A 50MB HTML report isn't unusual when the content is rich.

Why the file got big in the first place

A few common contributors, in order of typical weight impact:

• High-resolution images embedded as base64. A single 1920×1080 photo base64-encoded adds ~2-4MB to the HTML. A report with five embedded images can land at 15-20MB just from photos.
• Inline chart libraries + data. A Plotly chart bundle is around 3-4MB minified; the underlying data (a few thousand rows of JSON) adds another 500KB-2MB per chart.
• Embedded video clips. Short video embedded as base64 is 5-30MB per clip. Most reports avoid this; the ones that don't go big fast.
• Inlined external dependencies. Tailwind compiled to a static CSS file is ~5-15KB; a generic Tailwind CDN inline is 250KB+. Fonts inlined are 30-80KB per family.

The self-contained inlining work is the same step that makes the file portable and makes it large. The two goals are aligned (one file, opens anywhere); the size is the trade-off.

For AI-generated pages specifically, the typical default output before trimming is in the 2-5MB range. Reports with embedded multimedia push past 25MB without trying.

The three options when the file won't email

1. Compress (gzip / zip)

Compressing the HTML reduces size 50-70% typically. A 50MB HTML becomes a 15-25MB zip file — close to the email cap, often within range.

Trade-off: the recipient receives a zip, not an HTML file. They have to extract it before opening; some recipients (especially less-technical ones) get confused by the unzip step. The HTML inside the zip works fine once extracted, but the extra step kills the "click and read" feel.

When this fits: technical recipients who are comfortable with archives, internal team distribution where the unzip step is a known pattern.

When it doesn't: external client delivery where the receiver might not unzip and the report doesn't reach them at all.

2. Cloud drive (Google Drive / Dropbox / OneDrive)

Upload the HTML to a cloud drive; share the drive link. The receiver clicks; the drive's UI loads; the receiver clicks the file to download or preview.

Trade-off: the receiver lands on the drive's interface before the report. The framing reads as "here's a file the sender stored" rather than "here's the report." For internal sharing where the drive is already in use, this is fine; for external delivery where the receiver isn't part of the sender's drive ecosystem, it adds confusion.

The preview behavior also varies — most drive providers render HTML as code rather than as a webpage, so the receiver has to manually choose "open in browser" or download-then-open.

When this fits: distribution within an org where the drive is the shared workspace anyway.

When it doesn't: client-facing delivery where the drive UI is in the way of the report.

3. Private link host

Upload the HTML to a private-link host; the host serves it at a URL. Email the URL instead of the file.

Trade-off: requires using a separate service. For occasional large files this is overhead; for recurring delivery this is the obvious shape (the workflow becomes "ship the file" instead of "fight email's limit").

When this fits: most external delivery, most recurring report cycles, anything where the receiver should land on the report directly rather than on a drive UI.

When it doesn't: pure one-off cases where setting up an account isn't worth it (in which case the cloud-drive option is often easier).

The walkthrough — private link path

For a 50MB HTML that needs to reach an external client:

1. Drop the file at a private-link host. Most hosts handle files up to 100MB on paid tiers; the Free / No-account tier on most hosts caps lower (often 3-10MB), which is the limit that pushes most large-report cases to the paid tier.
2. Configure the link — password if the content is sensitive, expiry matching the engagement window, custom domain if the URL framing matters.
3. Email the URL only. The email itself is now tiny; no attachment limit applies.
4. The receiver clicks the URL, the page loads, the report renders in the browser. No download, no unzip, no drive UI.

For client deliverables specifically, this is the same flow as smaller files — the only difference is the file's size made the email path impossible.

Trimming first vs hosting it as-is

Before resorting to a host for size reasons, two passes are worth running:

• Convert images to WebP and re-base64. A 4MB PNG becomes a 600KB-1MB WebP at visually equivalent quality. Squoosh handles this locally in the browser.
• Externalize what doesn't need to be inline. Charts that pull data from a permanent API endpoint stay external; logos and decorative images go base64; large photos either stay external (with a stable URL) or get compressed aggressively.

For lightweight AI pages specifically, the same trim techniques apply.

Once the trim pass is done, if the file is still big, that's because the content genuinely needs to be that big — extensive data, multiple high-quality charts, multimedia content the report depends on. At that point, the host path is the right shape.

What this isn't

For files above 500MB — large video archives, design source files, dataset dumps — neither email nor most private-link hosts are the right shape. The dedicated file-transfer category (WeTransfer for one-off, MASV for media-industry workflows, S3 + signed URL for technical workflows) handles those.

For HTML specifically, 500MB is past the point where the file is meaningfully "an HTML file you open in a browser" — most browsers struggle with files that large. If a report is 500MB of HTML, the right move is usually to restructure it into a deployed dashboard rather than ship as a single file.

The right framing: email is sized for small attachments; private-link hosts are sized for medium files (up to ~100MB) delivered as URLs; dedicated file transfer is sized for everything bigger. The size of the content picks the shape, not the other way around.