Why Emailing an HTML File Breaks (and What to Do Instead)

Attaching an HTML file to an email is the most intuitive way to share a web page and one of the least reliable. The failure is not random — mail providers deliberately treat HTML attachments as hostile. This explains why, and what to send instead.

The Problem

Send someone an HTML file by email and you get one of five outcomes, roughly in order of frequency:

1. Silently stripped. The message arrives without the attachment. Neither of you is told.
2. Quarantined. It goes to spam, or an administrator holds it for review.
3. Warned. It arrives with a red banner telling the recipient the file may be dangerous. Most people stop there, correctly.
4. Delivered as text. They open it and see markup.
5. Works. They download it, open it in a browser, and it renders — minus any CSS, images, or scripts that were in separate files you did not attach.

Only the last one is a success, and it is conditional. You cannot tell which outcome you got, because nothing reports back. The failure is silent, which is what makes it expensive: you assume the ball is in their court and they assume you never sent it.

Why Providers Treat HTML Attachments as a Threat

This is not overcaution. An HTML attachment is a well-known phishing technique.

Here is the attack. An email carries invoice.html. The recipient opens it. It renders a pixel-accurate Microsoft or Google login page — locally, from their own disk. The address bar shows a local file path, so none of the usual “check the URL” advice helps. Credentials get posted to the attacker’s server.

Everything that makes an HTML file useful to you is what makes it useful to an attacker:

• It renders. It can look exactly like a real site.
• It runs scripts. So it can capture and exfiltrate input.
• It is self-contained. No suspicious link for a filter to check against a blocklist.
• It is a plain text file. Trivially mutated to defeat signature-based scanning.

Given that, stripping HTML attachments is the correct default. It is not going to be relaxed, and no trick you apply to get around it will be reliable for long.

The Solution

Host the file and send a link.

This inverts every property that made the attachment problematic. The recipient’s browser fetches from a real URL they can inspect. Nothing lands on their disk. It renders identically on their phone. And your assets travel with it, because you uploaded the whole thing rather than one file.

Mechanically it is one step: upload the .html file, or a .zip if the page has separate CSS, JS, and images, and paste the URL where you would have put the attachment.

Undraft does this and adds the piece the attachment never had: reviewers can pin comments to elements on the live page. Since the reason you emailed the file was almost always to get a reaction to it, the reaction now has somewhere to go other than a reply thread describing which part of the page it refers to.

The Workarounds, and Why They Are Not Worth It

Zipping it. Often gets past the filter. The recipient now has to download, unzip, locate index.html, and open it in the right application. Every one of those steps loses people, and some scanners inspect archives regardless.

Renaming to .txt. Works to deliver, then requires the recipient to rename it back. You are asking a client to do file surgery.

Pasting the HTML into the email body. Different thing entirely. Mail clients render HTML email under heavy restrictions — no scripts, limited CSS, unpredictable layout across clients. An interactive page will not survive it.

Cloud drive link. Delivers the file, does not render it. Drive and Dropbox are storage, not web servers; the recipient gets a preview panel or a download prompt.

All four are effort spent recreating something a URL does for free.

Examples

Before

1. Monday: you email dashboard.html to a client.
2. Thursday: you follow up.
3. Friday: they reply that they never got an attachment.
4. You zip it and resend.
5. They unzip it, open it, and see an unstyled page because dashboard.css was in the same folder but not in the zip.

Five days, no review.

After

1. Monday morning: you zip the folder and upload it.
2. You email the link.
3. Monday afternoon: they open it on their phone in a meeting, click three elements, and leave three comments.
4. Tuesday: you upload a revision to the same link.

One day, three specific notes.

Summary

• Send a hosted link, never an HTML attachment — providers strip these by design and will keep doing so.
• Watch for silent failures in your current process — if follow-ups routinely go unanswered, check whether the attachment ever arrived.
• Avoid the zip-and-rename workarounds — they add friction for the recipient and still lose the assets that make the page work.

Next: the direct guide to share an HTML file as a live link, and how to comment on a webpage once it is hosted.