Guides

Stop printing your HTML to PDF

If Claude just handed you a good HTML report, model, or proposal, don't convert it to PDF — publish the HTML to a URL and send the link. The HTML is the deliverable; the PDF is a lossy print of it. The print step throws away three things you already paid for: the interactivity your agent built, the ability to correct the document after it's sent, and any signal about whether it was read. If all you need is a page on the internet, free static hosting will do that and we'll point you to it below. This piece is about why the print costs more than it looks, and what a link can do that an attachment never will.

Why is PDF the reflex?

Because attachments are how documents move, and PDF is the one format every recipient opens without thinking. The instinct is right about the problem and wrong about the fix.

Send the raw .html file instead and things genuinely break. In the 14 practitioner interviews behind our product spec, one operator described emailing HTML deliverables: "but in outlook it just shows the raw text file… have to explicitly tell them download it and open it in a browser." Nobody wants to open a client conversation with browser instructions. So the file gets printed to PDF, the rendering problem disappears — and most of what made the HTML worth having disappears with it.

There's a second push in the same direction: the chat window is a bad place for a finished document to live. One Hacker News user, theptip, on agent-built documents: "It's equivalent to the in-browser Artifact workflow but that's kinda annoying to work with, I usually want to export those outside of the chat client at some point" (HN). The export reflex is healthy. The only question is whether the export target is a frozen file or a live URL.

What exactly does the print throw away?

Three things, in increasing order of how much you'll miss them.

Interactivity becomes ink

Claude doesn't produce documents so much as web pages: calculators the reader can drag, toggles between scenarios, charts that respond to hover, tabs that keep a long report navigable. Anthropic's Claude Code team made the case for this directly in The unreasonable effectiveness of HTML (May 2026): HTML lets the model structure its output visually — tabs, illustrations, links — and add lightweight interactivity that flat formats can't carry.

A sensitivity model where the reader drags the discount rate and watches the valuation move is a different artifact from a table printed at one set of assumptions. Print it to PDF and the reader gets your defaults, forever, with no way to ask the document a question.

The content freezes at export

A PDF is correct for exactly as long as nothing changes. The first correction after sending means exporting again and re-sending, and now two versions of the truth sit in the recipient's inbox with a third named v3-FINAL-final on the way. You cannot fix a number in a file you have already emailed, and you never know which copy they opened.

An HTML artifact at a stable URL inverts this. Republishing updates the page in place: the link you sent Monday serves Thursday's numbers. Every version is retained and you can roll back, so a bad edit is a pointer flip rather than an apology email. Readers who saved the link from the original thread still land on the current version. The document stops being a series of files and becomes one address.

The read signal disappears

An emailed attachment is a black hole. You learn nothing — not whether it was opened, not whether the reader got past the executive summary, not whether it was forwarded to the person who actually decides. Every follow-up is written blind.

A link can answer those questions. A published artifact records views by day and by version, distinct viewers, active read time — time the page was actually in front of someone, not just an open tab — and how far each reader scrolled, with bot hits and unrendered link previews filtered out so the numbers mean something. Gate the artifact on an email address and the signal gains names: you know who read for six minutes and who bounced at the first chart. That changes the follow-up from "checking in" to a specific note about the section where they stalled.

This is the part the format debate usually skips. Even Anthropic's own training flow for creating a sales proposal — a document whose entire purpose is to be delivered and read — ends when the deck is "ready to present." Generation is treated as the finish line. Everything after the handoff is left as an exercise, and the handoff is where deals are won or quietly lost.

What about the AI on the other side?

Increasingly, the first reader of your deliverable isn't a person. It's the recipient's agent — summarizing the document, extracting the numbers, folding it into their own context before a human sees a word.

HTML survives that intact. It's structured text: headings, tables, and lists arrive as headings, tables, and lists, the same shapes the model reads and writes natively. A PDF is a print layout — text positioned on a page — and getting structure back out of it means extraction or OCR, where tables and hierarchy are the usual casualties. If your document will be parsed as often as it's read, send the structured original, not a picture of it.

When is a PDF still the right call?

Whenever the recipient needs to hold a copy. Contracts going to signature, regulatory filings, anything archived under someone else's retention policy, print, genuinely offline readers. In those cases a PDF isn't a lazy default; it's the requirement.

Note the asymmetry, though. A serviceable PDF can always be derived from the HTML — every browser prints a page — but the HTML can never be recovered from the PDF. Keep the HTML canonical and derive the frozen copy when someone needs one, not the other way around.

If you only need a URL, hosting is free

Worth saying plainly: getting HTML onto the internet costs nothing. GitHub Pages, Netlify, or an S3 bucket will host a static page for free, and for a throwaway share that is the right amount of infrastructure. We're also not the only ones making the format argument — skip the print, publish the HTML — and on the format question we agree with everyone making it.

The differences start after the link is sent.

How do you actually publish the HTML?

Whatever produced the file, publishing is one step.

• One-off: drag the file onto the drop-zone at sendartifact.com.
• From a shell: npx @sendartifact/cli publish ./out --slug q3-report, after a one-time npx @sendartifact/cli login. Republish the same slug to update in place; the URL never changes.
• From the agent itself: a skill file at sendartifact.com/skill.md teaches any agent the full flow through that same CLI, onboarding included — it signs you in, publishes, updates, and reads the analytics back to you.

Every publish is private by default; you widen access deliberately. Invite specific guests by email address, or a whole domain — acme.com covers the entire Acme team. Or open it to anyone with the link, or make it fully public. On the open modes you can require the reader's email before the page renders: self-reported when you just want to know who's reading, or verified with a one-time code when the answer has to be trustworthy. Readers never need an account. The limit is 25 MB of static files.

What happens after the link goes out?

Two things an attachment cannot do.

First, you see readership: opens by day and by version, distinct readers, active reading time, scroll depth, and identities where you've gated on email — bots filtered out. When the response to a proposal is silence, you can tell the difference between "never opened it" and "read it twice and stopped at pricing," and those call for different next moves.

Second, readers can respond in place. Comments are anchored to the passage they're about, so feedback arrives attached to the exact paragraph instead of paraphrased three days later in an email. The comments queue for you, and nothing happens to the document on its own. When you decide a piece of feedback deserves action, you point your agent at the thread — the CLI's comments and resolve commands carry it both ways — and it makes the edit, republishes to the same URL, and replies to the commenter describing what changed. The reader gets a fixed document at the link they already have; you stay in control of every change.

The PDF was never really a decision. It was the path of least resistance when documents were files and files moved as attachments. The moment your document has a stable URL, the print step stops solving anything and starts costing you: the interactivity your agent built, the ability to fix on Thursday what you shipped on Monday, and every signal about whether anyone actually read the thing. Publish the HTML. Send the link.

Questions — support@sendartifact.com.

Published 2026-08-27 · markdown twin at /guides/publish-html-not-pdf.md · questions: support@sendartifact.com.