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.
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.
A Claude artifact looks self-contained inside the chat and often isn't. The five things that quietly stay external — CDN scripts, Tailwind, fonts, images, fetch calls — and how to inline each.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.
There is no single number — it depends on the model, the image size, and whether you send a PDF as text or pixels. The per-model formulas, real measured costs, and how to count it for your own model.
You finish a document and hit the same fork every time: send it as a PDF because that feels official, paste it into a shared doc, or just attach the file. The format gets picked by habit. But Markdown, HTML, and PDF were each built for a different job — and picking by habit means a good fraction of the time, the format is quietly fighting the work.
The fix is to stop asking which format is best and start asking best for which job. There are three jobs.
Each format is the answer to a different question:
Most "which format" arguments are really two of these being compared on a job neither was built for.
Markdown is plain text with a few characters of structure: # for headings, - for lists, | for tables. That buys two things — it sits close to the token floor for an LLM (the token math is decisive), and it is trivially version-controllable, diff-able, and editable in anything.
Where it is the right shape:
Where it is not: the final thing you hand a client or an exec. Raw Markdown reads as code to a non-technical person — the ## and | show on screen instead of a formatted page. Markdown is an excellent source and a poor finish.
HTML is the rendered, living format — what Markdown becomes when a person actually needs to read it: a real page, with styling, interactivity, and a URL.
Where it is the right shape:
Where it is not: a signature workflow, a regulatory filing, or an offline archive. HTML is alive, which is the wrong property when you need something frozen.
PDF's whole job is to not change: fixed pagination, embedded fonts, identical on every device, frozen at export. That is a liability for AI input and interactivity, and exactly right where stability is the point.
Where it is the right shape:
Where it is not: feeding a machine (token-heavy and extraction-noisy) or a living deliverable (it flattens interactivity and forks into everyone's Downloads).
| The job | Reach for |
|---|---|
| Feed a document to an AI | Markdown |
| Author / maintain a source document | Markdown |
| Hand a person an interactive or living deliverable | HTML |
| Share a report someone opens in a browser | HTML |
| Get something signed | |
| File, print, or archive a fixed document |
If a format keeps feeling slightly wrong for what you are doing, it is usually because it is being used on another column's job.
Here is the part that dissolves most of the argument: you rarely have to choose. The three formats line up as a sequence, each handing off to the next.
Most friction comes from skipping a step: handing someone raw Markdown, feeding an AI a PDF, or treating an HTML link as the archival record. Match the format to the stage and each step gets easier.
The middle step — turning the document into a page a person opens — is where a link beats a file. Drop the HTML, get a private link in under 60 seconds. No card, no account, 7-day self-destruct.
A few mismatches worth naming, because they are the common ones:
None of these are wrong files. They are right files on the wrong job.
For the delivery step specifically — turning the HTML into something a person opens — the channel choice is its own decision: a private link for one audience, a public host for reach, an attachment when you know the device.