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.
The team ships the report Friday afternoon. Thirty-eight megabytes, twenty-two pages, three appendices, a chart per stakeholder. Sunday night, the executive opens the PDF on a phone. The first chart renders at 8pt. The methodology footnote is on page 19 and there's no way to jump from the chart on page 4 to the footnote that explains it. By Monday morning, the report's been forwarded twice and there are now three copies in three different inboxes, plus a fourth in the team's shared drive.
The content was fine. The container did three things at once: shrank the type, lost the interactivity, and forked into four copies, each of which will outlive the next quarterly version.
Each of those is a different argument for a different container. Together, they're the case for HTML.
PDF is one of the best things the software industry has shipped. Twenty-something years of universal cross-platform rendering, identical output on every device, paginated for print, opens in every browser, every OS, every screen reader. The format has earned the role it plays — the lawyer's contract, the printed leave-behind, the regulatory filing, the invoice you'll need in seven years for the audit.
The shape that makes PDF strong for archive — fixed pagination, embedded fonts, frozen-at-export — is the shape that pushes against the read-through phase of a modern deliverable. Both can be true.
An interactive report does things the printed page can't:
In PDF, every interactive piece becomes a flat screenshot. The chart is there; the question-asking isn't. For a deliverable where the interactivity is the analysis — most data work, most dashboards, anything with a "what if" — that's the difference between the reader using the report and reading about it.
A 30 MB PDF and a 200 KB HTML link arrive in the same email. They're not opened the same way.
For an executive reading on a phone between meetings, that's the difference between opens the report and saves the report for later, doesn't come back to it. The data hasn't changed. The friction in front of the data has.
The weight is also a downstream cost: 30 MB PDFs forwarded around an org are 30 MB per inbox, in storage that someone pays for. HTML links forward as text.
This is the one that goes unnoticed until the team revises the report.
A PDF report sent on Friday lives in:
The team updates the report on Tuesday — fixes the segmentation methodology that flagged in the Monday meeting. They send a new PDF. Now there are six copies of the old version and one copy of the new version. For at least the next six weeks, half the time someone opens the report they'll open the stale one.
An HTML link at a stable URL avoids the fork entirely. Update the file at the link; everyone who has the link sees the new version on the next open. The Downloads folder still exists; there's just no PDF in it to compete with.
For deliverables that revise — quarterly reports, ongoing engagements, anything where the numbers change — single source of truth is a structural property, not a discipline question.
Drop an HTML report or interactive deliverable, get the private link in under 60 seconds. No card, no account; the file self-destructs after 7 days — useful for sanity-checking the flow before sending to a real client.
Worth saying before the mechanics: this piece argues HTML against PDF for one job — the deliverable a person opens. It isn't a claim that one format wins everywhere. Markdown, HTML, and PDF each answer a different question — what goes into a machine, what a person interacts with, what gets frozen for signature — and the cleanest workflow uses all three in that order.
For most teams, the deliverable is already produced in a tool that supports both formats:
For consulting dashboards specifically, the interactivity axis carries most of the weight; for agency previews, it's the framing and the single-URL property.
The thread across all of them: the format that the deliverable was built in is usually a closer fit to HTML than to PDF. The conversion to PDF is a transformation; the conversion to a self-contained HTML file is usually a save.
The HTML file needs a URL. The choice is mostly about whether the file should be public, internal, or sent to a specific list:
For client deliverables and reports going outside the team, the third option is usually the cleanest match — the URL behavior matches what the client expected when they tapped the link.
Solo plan ($4.99/mo) makes the link permanent and removes the footer. Studio ($14.99/mo) adds custom domain so the URL lives at the team's own subdomain. Privacy and password protection are always free; paid tiers are about persistence and ownership of the URL.
HTML doesn't replace PDF. The cases where PDF is the right shape are real and stay that way:
For the read-through phase of a deliverable — the days the team and the client are actually engaging with the work — the three axes above compound enough that HTML is usually the better shape. After sign-off, an archival PDF can ship alongside, sized for the auditor and the printer.
The format choice is less about which is better and more about which is the right shape for this stage of the deliverable's life. Most engagements have both stages; most teams ship only the second.
The document where this bites hardest is the one people are most reluctant to move: a pricing proposal. It gets read on a phone, skimmed selectively, and returned to — a read-through document by every measure — yet it ships as a PDF almost universally, because the signature at the end drags the whole thing into archive shape.
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 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.
Three formats people reach for by habit, built for three different jobs. A job-by-job map of when Markdown, HTML, or PDF is the right shape — and why they work best as a pipeline, not a choice.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.