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.
You attach the .html file. It sends, it arrives, nobody's security team complains. Then your recipient replies:
"It's just a page of code?"
And they paste back something starting <!DOCTYPE html>. This is common enough that university IT departments keep knowledge-base articles about it. It's also the failure people most often misdiagnose, because it looks like the file broke in transit.
Almost every "I emailed an HTML file and it didn't work" is one of these, and the fixes point in different directions:
| What happened | What they see | What it actually is |
|---|---|---|
| Blocked | Nothing, or a security notice | The provider stripped or quarantined it |
| Too big | A bounce message | A size cap on the receiving side |
| Raw code | <!DOCTYPE html> and a wall of markup | It arrived fine and is being read rather than run |
If they can quote your markup back at you, you are firmly in the third row. Nothing was blocked. Nothing bounced. The file is byte-for-byte what you sent.
An inbox preview shows you what a file contains. It deliberately stops short of executing it — and the reason is worth understanding, because it explains why no attachment format will fix this.
Your mail client is already authenticated as you. If it ran attached HTML the way a browser does, anyone who could email you could execute markup and scripts inside a page holding your live session. Every mainstream provider decided long ago that the safe answer is to display the characters. That's the same instinct behind Google Drive showing your uploaded page as code rather than serving it: both are storage-and-reading environments, and neither is willing to become a web host by accident.
So the raw code isn't a bug you can route around with a better attachment. It's the correct behaviour of a tool doing a different job.
Zip it. Gets past filters. Now they download, unzip, locate index.html, and know it belongs in a browser. Fine for a developer. On a phone, that chain often ends with "there's no app to open this file," and you're troubleshooting someone else's device.
Paste it into the body. Works for styled text and nothing more. Mail clients strip scripts and ignore most modern layout, and each renders differently — so anything interactive arrives as a flattened shell that makes your work look worse than it is.
Rename to .txt. Removes the confusion, delivers nothing.
Send a link instead. Changes what the message carries. No attachment to strip, no size ceiling to hit, nothing for the preview pane to read as text. The email carries an address; the page opens in a browser, which is the one place HTML is designed to run. It's the same move as choosing a hosted link over emailing a zip, and it clears all three rows of that table at once rather than one.
If the file never arrived — no bounce, no attachment, just silence or a policy message — that's the blocked case, and it's decided by software inside their organisation. Why the link you sent got blocked covers what's making that call and what you can influence.
If you got a bounce about size, that's a cap on the receiving side, and it belongs to itself: sending a 50 MB HTML file when email refuses.
Raw code is neither. It's the friendliest of the three, because it means everything worked except the last step.
Drop the .html file into miinideck and paste the URL into the email you were already writing. The page renders live in their browser — charts draw, interactions work, no download, no unzip, no account on their end.
The link is unguessable and no-indexed by default, so it isn't discoverable. Add a password if the contents warrant it, or an expiry so it doesn't outlive the project — both free on every plan. Replace the file later and the address doesn't change, so you never send a "please ignore the last one" follow-up.
Free covers one always-on link and 10 MB per file, with other links defaulting to a 7-day expiry. Solo ($4.99/mo) makes links permanent and adds the detailed access log; Studio ($14.99/mo) adds a custom domain and white-labelling.
One caveat worth stating plainly: this is for pages that run in the browser. If your build needs a server, a database, or saved form submissions, put it on a platform made for that — Vercel and Netlify both do it well — and send that link instead.
You send a delivery link, the reply is 'blocked by our security policy.' Nothing is wrong with your file. Here's what actually inspects a link between you and them, why unfamiliar domains lose that inspection, and what you can do from your side.
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.
PDF is built for archive and print. HTML is built for live, browser-native delivery. Where the three differences — interactivity, weight, single source of truth — actually decide which format ships.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.