Guide

Why HTML documents break when you send them (and what to do instead)

Claude, ChatGPT and Gemini will write you a genuinely good document — headings, tables, charts, a proper layout — in about thirty seconds. What they hand back is a file full of HTML. That file is the problem, and it is worth understanding exactly why before choosing a way around it.

What HTML actually is, in this context

An HTML file is not a document in the way a PDF or a Word file is. It is a set of instructions that a browser follows to draw a page. It usually depends on things that are not inside the file: fonts loaded from the web, a chart library fetched from a CDN, scripts that run when the page opens.

That is why it looks perfect on your machine — your browser has everything it needs. Sending the file to someone else means sending the instructions without any guarantee that their software will follow them the same way, or at all.

The three usual options, and what each one costs

1. Attaching the .html file

This is the most common instinct and the least likely to work. On a phone — where most clients read their email first — tapping an .html attachment often opens a text view of the source code, downloads a file the person cannot open, or does nothing at all. Some corporate mail filters strip HTML attachments entirely, because they are a known phishing vector, so the recipient may never see it.

Even when it opens, an unfamiliar .html attachment looks suspicious to a non-technical reader. A meaningful share of recipients simply never click.

2. Printing to PDF

The safest-looking option, and the one that fails most quietly. Three things go wrong routinely:

• Interactive charts flatten. Anything drawn by JavaScript after the page loads may capture mid-animation or not at all, so a chart becomes an empty box or a set of half-drawn bars.
• Wide tables lose their right-hand columns. On screen a wide table sits in a scrollable box. Paper has no scrollbar, so whatever does not fit is simply cut off. The numbers are gone and nothing indicates they were ever there — this is the failure worth fearing most, because nobody notices until a client asks about a figure that is not in the document.
• Non-Latin text can vanish. If the tool converting the file lacks fonts for Chinese, Japanese, Arabic, Thai or Indic scripts, the layout renders correctly with the text missing. It looks like a design problem rather than a font problem, which is why it goes unnoticed.

If you do print to PDF, open every page of the result before sending it, and pay particular attention to the right edge of any table.

3. Screenshotting it

Reliable in the sense that it always displays, and lossy in every other sense. The text stops being text: it cannot be searched, copied, quoted back to you, translated, or read by a screen reader. On a phone the reader is pinching and zooming a picture. For anything longer than a page it is a poor experience.

How to choose

There is no single right answer — it depends on what the document is for.

• The client needs to file, sign or print it. A PDF is correct. Check the wide tables and export at a sensible page size.
• The client needs to edit it. Word, accepting that complex layouts will shift. Text and tables carry over well; multi-column designs and custom graphics generally do not.
• The client just needs to read it, probably on a phone. A link is better than any file. Nothing to download, renders as designed, and works the same on every device.
• The document is genuinely simple. Paste it into the email body as rich text. Not everything needs a tool.

Free ways to send it as a link

You do not need to pay anyone for this. Reasonable options:

• GitHub Gist + a static viewer, or GitHub Pages if the document belongs in a repository. Free, though the URL looks technical and the setup is a few steps.
• Netlify Drop or Cloudflare Pages. Drag a folder in, get a URL. Genuinely free and reliable; you get a hosting subdomain rather than anything branded, and no preview card in chat apps.
• Notion or Google Docs, if you are willing to paste the content and lose the original design. Fine for text-heavy documents, frustrating for anything with charts.

All of these work. What they generally do not do is produce a proper preview card when the link is pasted into WhatsApp or WeChat, keep a clean export path to PDF and Word, or let you fix a typo without sending a new link.

What SendPage does

SendPage is built for the third case above. You paste the HTML and get a link. The recipient taps it once and reads the document as designed, on whatever phone they are holding. The link previews in WhatsApp and WeChat with your title and a thumbnail of the real document rather than a bare URL.

Exports come from an actual browser render rather than a converter, so what you see is what the file contains: wide diagrams turn the page to landscape instead of losing a column, and Chinese, Japanese, Arabic, Thai and Indic text export with their fonts intact. You can also correct a mistake after sending — the link stays the same, so there is no follow-up message apologising for version two.

It is free for five documents a month with no signup, which is enough to find out whether it helps. Try it with a document you have already written.

The short version

An HTML file is a set of drawing instructions, not a document, and it stops being reliable the moment it leaves your machine. Send a PDF when the reader needs a file, send Word when they need to edit, and send a link when they just need to read it — which, for most client documents, is what they actually need.