In the HTML vs PDF choice, the deciding question is whether the content will change again. PDF freezes a layout, HTML keeps a document you can correct at the same address.
Everything else, file size, fonts, printing, follows from that one difference. So does most of the frustration on both sides.
Row by row
| Property | HTML | |
|---|---|---|
| Layout on a narrow screen | Reflows to the width | Fixed page, zoom and pan |
| Correcting a mistake | Edit at the same address | Regenerate and resend |
| Charts and tables | Stay interactive | Become a picture |
| Printing exactly | Needs a print stylesheet | Native strength |
| Offline reading | Needs a self contained file | Native strength |
| Signing and archiving | Not designed for it | Native strength |
| Screen reader support | Good with semantic markup | Depends entirely on tagging |
| Version drift | None, one address | Every copy is a fork |
Four rows favour HTML, three favour PDF, and one depends on how the file was made. That is a genuine split, not a landslide.
The case for PDF, stated fairly
PDF exists because some documents are about their layout. A contract, a certificate, an invoice with a legally required form.
It also wins on offline reliability. A PDF on a laptop opens without a network, in a viewer that already exists, with predictable pagination.
And it is the archival format organisations already trust. If someone has to keep the document for seven years, PDF is the answer and there is no argument to have.
The case for HTML
Most documents sent inside companies are not about layout. They are about numbers, status and instructions, and they will be wrong within a month.
An HTML page at a stable address absorbs that. Fix the figure and every link already points at the fix.
It also matches how people read now. A page with a viewport meta tag fits a phone screen without zooming, and most internal reading happens on a phone.
And it keeps interactivity alive. A sortable table stays sortable, a chart keeps its tooltips, a filter keeps filtering.
Where PDF quietly costs you
Three costs that do not show up until after you send it.
- Version forks. Every copy is frozen. A correction means a second file, and now two versions circulate with no way to tell which is current.
- Dead interaction. The chart you built for hovering is now a flat image, and the sortable table is a picture of one ordering.
- Attachment friction. Mail gateways, chat cards and phone file managers all sit between the reader and the content.
None of these matter for a signed contract. All of them matter for a weekly report.
A practical rule
| If the content | Send |
|---|---|
| Is final and legally significant | |
| Must print to exact page geometry | |
| Will be read offline on a plane | PDF, or a self contained HTML file |
| Has numbers that will change | HTML at an address |
| Contains a chart worth using | HTML at an address |
| Is read weekly by the same people | HTML, same address every week |
| Is being discussed in a channel | HTML with a preview card |
Notice that PDF wins on properties of the document and HTML wins on properties of the reading. Most internal content is the second kind.
You do not have to choose once
Keep HTML as the source and produce a PDF when someone asks for one. That direction works cleanly.
A print stylesheet controls page breaks, hides navigation and sets colours for paper. The browser's own print to PDF then gives you a serviceable file.
The reverse direction is painful. Converting a PDF back into a working page means reconstructing structure that was thrown away at export time.
So when both are needed, author in HTML. Treat the PDF as an output format, not a storage format.
Getting the HTML side to actually arrive
The most common reason people fall back to PDF is that sending HTML went badly, usually because they sent the file.
Give the page an address instead. Paste the HTML into a NOS document and it renders exactly as written, dark theme, charts and scripts included.
Take the link from Share, then Share link, then Create link. It is unlisted by default, so it opens for whoever holds it and is not listed anywhere.
The address does not move when you edit, which removes the version fork problem that pushed you toward PDF in the first place.
For the same comparison framed around a single deliverable, see PDF versus an HTML page. If the reason for PDF is accessibility policy, the accessibility comparison covers what the standards actually require.
If the alternative you are weighing is a screenshot rather than a PDF, screenshot versus live page is the shorter answer. To try the link route now, paste a report into the HTML to link tool.