You build a report, save it as report.html, open it locally, and it looks exactly right. You email it to a colleague and they reply: "it's blank" — or worse, they send back a screenshot of raw markup.
This is one of the most common frustrations with single-file HTML, and it is almost never a problem with your file. It is a problem with how the file travelled.
What is actually going wrong
There are four separate failure modes, and they look identical to the person receiving the file.
1. The client downloaded it instead of rendering it
Email clients, Slack, Teams and most chat tools treat .html as an attachment to download, not a document to display. This is deliberate: rendering arbitrary HTML inside a mail client would be a serious security hole, because HTML can carry scripts.
So your recipient gets a file on their disk. Whether it opens correctly then depends entirely on what they double-click it with.
2. It opened in the wrong application
On a machine where .html is associated with an editor rather than a browser, double-clicking shows the source. Plenty of people have never opened an HTML file directly and have no default set at all.
3. Corporate security stripped it
Many mail gateways rewrite or quarantine HTML attachments, precisely because they are a phishing vector. Some strip the <script> tags and deliver a gutted file. If your page builds its content with JavaScript — which most AI-generated dashboards do — removing the scripts leaves you with an empty <body>. That is your blank page.
4. It depends on files that did not travel with it
If your HTML references a separate stylesheet, a chart library from a CDN, or a local image, those have to resolve on the recipient's machine. Relative paths break the moment the file moves. A blocked CDN on a corporate network produces the same result.
The three fixes that actually work
Fix 1: Publish it to a URL
This solves all four failure modes at once, because you stop sending a file altogether. A URL loads in a browser — the one application guaranteed to render HTML properly — with the scripts intact and the assets resolving from the same origin.
It also fixes the things you did not know were broken: the page works on a phone, it works for someone who never downloads attachments, and it renders a preview card in Slack instead of an anonymous paperclip icon.
You can publish an HTML file to a link directly, or if an AI assistant wrote it, publish straight from the assistant without the download-and-re-upload step in the middle.
Fix 2: Inline everything, then send the file anyway
If you genuinely must send a file, make it truly self-contained:
- Put CSS in a
<style>tag rather than a separate.cssfile. - Put JavaScript in a
<script>tag rather than linking a CDN. - Embed images as base64 data URIs instead of referencing image files.
This fixes failure mode 4 and helps with nothing else. The recipient can still download it into an editor, and a mail gateway can still strip your scripts. Treat this as a fallback, not a solution.
Fix 3: Convert it to PDF
Print to PDF and you get a format every device opens predictably. The cost is everything that made the page worth building: no interactivity, no working links, no responsive layout, no live charts. If your page is a static document anyway, this is a perfectly reasonable answer. If it is a dashboard, you have thrown away the dashboard.
How to tell which one you hit
Ask your recipient one question: do you see nothing at all, or do you see code?
- Code means the file opened in an editor, or a viewer served it as plain text. Failure mode 2.
- A completely blank white page usually means the scripts were stripped or blocked. Failure mode 3, sometimes 4.
- Partial content with broken styling means the assets did not resolve. Failure mode 4.
- "I can't open it at all" usually means their security policy quarantined the attachment. Failure mode 3.
Why this keeps getting worse
Two things changed recently. AI assistants got very good at producing single-file HTML — dashboards, reports, interactive one-pagers — so far more people are generating HTML who never used to. And security filtering on HTML attachments got stricter, for good reasons.
The result is a lot of people producing genuinely good pages that will not survive being emailed. The file was never the deliverable. The rendered page was.
Check your file before you send it
If you want to confirm your HTML renders the way you expect, paste it into the free HTML viewer — it renders in a sandboxed frame in your own browser, with scripts running, and nothing is uploaded. If it looks right there and wrong for your recipient, the problem is transport, not the file, and Fix 1 is your answer.