Email providers cap attachments around 20-25MB. The fix when the file is bigger isn't to compress harder — it's to send the URL instead.
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.
For reference:
| Provider | Outbound attachment limit |
|---|---|
| Gmail | 25 MB |
| Outlook.com / Hotmail | 20 MB (default; up to 34 MB via OneDrive replacement) |
| Yahoo Mail | 25 MB |
| iCloud Mail | 20 MB |
| Apple Mail (IMAP) | 25 MB (recipient-dependent) |
| Corporate Exchange | 10–15 MB (typical default) |
| ProtonMail | 25 MB |
| Tutanota | 25 MB |
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.
A few common contributors, in order of typical weight impact:
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.
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.
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.
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).
For a 50MB HTML that needs to reach an external client:
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.
For files under 3MB, the anonymous tier handles it; for larger files, the paid tiers raise the per-file cap. Either way, dropping the file and getting a URL takes under 60 seconds and skips the email-attachment dance entirely.
Before resorting to a host for size reasons, two passes are worth running:
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.
Solo plan ($4.99/mo) raises the per-file size cap and adds permanent links and detailed analytics — useful when the large report needs to be sent recurringly (quarterly reports, ongoing client engagements) rather than as a one-off. Password protection is free on every account, large file or small.
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.
The attachment arrived, nothing was blocked, and your recipient sees markup instead of the page. That's three different email failures people keep merging into one. Here's which one you hit, and why the fix isn't a different attachment.
Upload an .html file to Drive, open it, and you get a wall of markup instead of the page. Nothing is broken — Drive is doing exactly what a filing cabinet does. Here's the mechanism, the workarounds people try, and what actually renders it.
The page is fine. Your computer is fine. What differs is that a desktop knows what to do with an HTML file and a phone mostly doesn't — so the fix depends on whether you sent a file or an address. Here's how to tell which you sent.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.