Choose an HTML presentation when the recipient must use live navigation, animation, data, forms, or other browser behavior. Choose PDF when the deliverable should be fixed, downloadable, printable, and reviewable as pages. Neither format automatically provides privacy, accessibility, or proof of reading. For important delivery, publish HTML and offer a verified PDF fallback.
Choose HTML or PDF from the recipient task
The default question—“Which format is better?”—is too broad. A client reviewing a signed-off board pack, a prospect exploring a live calculator, a conference attendee printing notes, and a teammate checking an animated prototype have different jobs.
| Recipient task | Prefer | Reason |
|---|---|---|
| Explore live data, controls, animation, or conditional content | HTML | The browser executes the presentation's runtime. |
| Read, annotate, archive, or print fixed pages | The artifact freezes a page sequence. | |
| Always open the current revision at one link | Hosted HTML | The publisher can update the linked deck without resending a file. |
| Preserve a specific reviewed snapshot | PDF plus release identity | A file hash can identify the approved output. |
| Work without network access | Self-contained HTML or downloaded PDF | Offline capability depends on the complete artifact, not the extension alone. |
| Enforce viewer authentication or expiry | Either, behind an access system | File format is not an access-control policy. |
| Provide the safest fallback for an external recipient | Both | The live link preserves behavior; the PDF preserves readable pages. |
PDF is not merely a “worse HTML presentation,” and HTML is not merely a “more interactive PDF.” A PDF can be the authoritative record precisely because it does not change at viewing time. An HTML deck can be the authoritative experience precisely because the runtime is part of what the author intended to deliver.
What survived in a same-source HTML-to-PDF benchmark
We built a three-slide, zero-dependency HTML fixture with two observable browser behaviors:
ArrowRight changes progress from 1 / 3 to 2 / 3, and a button changes the second slide's text.
The same source includes print CSS that turns all three slides into 16:9 pages.
Chrome 151.0.7922.174 exported that exact source to PDF. Playwright verified the browser behavior;
pdfinfo and pdftotext inspected the generated file.
| Check | HTML result | PDF result |
|---|---|---|
| Artifact | 4,572-byte source.html | 192,701-byte rendered.pdf |
| Identity | SHA-256 49efac3…f6f5f | SHA-256 3f798b4…f7e7fc |
| Page/slide sequence | Interactive 1 / 3 → 2 / 3 | Three fixed 16:9 pages |
| Button behavior | Text changed after click | No form and no PDF JavaScript |
| Text | Browser-rendered HTML text | Slide text was extractable in this output |
| Tag observation | Semantic HTML in the source | pdfinfo reported Tagged: yes |
Open the interactive source, download the generated PDF, or inspect the machine-readable results and reproduction notes.
The result is deliberately narrow. It proves that this PDF retained three fixed pages and extractable text, while the source's key navigation and button state remained browser behavior. It does not prove pixel parity, PDF/UA conformance, universal PDF-reader behavior, or that every HTML interaction is lost by every export method.
MDN's printing guide
explains how print media queries and @page rules control printed output. Slidev's
official export guide likewise warns that interactive
features may not be available in exported files and distinguishes web hosting from PDF, PPTX, PNG,
and Markdown exports. Reveal.js maintains a dedicated
PDF export workflow rather than treating browser print as an
automatic equivalent of the live deck.
When an HTML presentation is the stronger deliverable
Use HTML when behavior is part of the message. Examples include a chart the recipient can filter, a code demo, a step-by-step reveal, an embedded prototype, a calculator, conditional navigation, or a deck that reads live data.
HTML's useful properties are:
- Runtime behavior. CSS and JavaScript can react to keys, clicks, messages, timers, and data.
- Responsive layout. A well-built deck can adapt to viewport size instead of freezing one page geometry.
- One current link. A publishing layer can update an owned deck while retaining the reader URL.
- Web semantics. Headings, landmarks, text, links, labels, and focus behavior remain available to the browser when authored correctly.
- Observable delivery. The host can record a qualifying browser open or interaction under a transparent analytics and consent policy.
Those properties carry responsibilities. The artifact must package its runtime and assets; the host must isolate uploaded code; the author must test keyboard, touch, mobile layout, reduced motion, network dependencies, and the exact reader context. A live browser deck can fail later if it depends on a remote resource that disappears.
The HTML presentation hosting guide covers the complete publishing model. Use the single-file vs multi-file guide to choose the artifact before publishing.
When PDF is the stronger deliverable
Use PDF when the reviewed page state is the product: an approval pack, printable handout, archival snapshot, procurement attachment, board record, or deliverable that must open as a known page sequence without executing the source runtime.
PDF's useful properties are:
- Fixed pages. The author can review the exact page sequence, size, and breaks before delivery.
- Downloadable snapshot. A recipient can keep the reviewed file without relying on the live host or its future revision.
- Print workflow. Page geometry and print intent are explicit when the export is prepared well.
- Release identity. The delivered file can be hashed and attached to an approval or archive record.
- Familiar handoff. Many external workflows explicitly request a PDF attachment or upload.
Those properties also carry responsibilities. Verify fonts, crop, page order, hyperlinks, text
extraction, reading order, document title, language, tags, color contrast, file size, and the target
PDF viewer. Tagged: yes is one observed metadata field, not an accessibility certification. A PDF
that looks correct can still have poor reading order or missing alternative text.
PDF can contain forms, links, media, or scripts in some viewers, but those capabilities introduce compatibility and security variability. This article compares a conventional static export. If an interactive PDF is required, define and test its supported readers separately instead of assuming browser behavior will carry over.
Compare the full delivery responsibility
| Responsibility | Hosted HTML | Shared PDF |
|---|---|---|
| Freeze the exact artifact | Hash the HTML or complete bundle. | Hash the exported PDF. |
| Preserve interactivity | Package and test the runtime. | Define only deliberately supported PDF interactions. |
| Control revisions | Update the owned deck and preserve version history. | Name/version files and resend or replace them in the delivery system. |
| Work offline | Make every dependency local and download the artifact. | Download the file and verify the target reader. |
| Protect access | Apply authentication, expiry, or allowlist at the delivery layer. | Apply equivalent controls in the file portal or document system. |
| Verify readability | Test browser, viewport, keyboard, touch, and clean session. | Test page sequence, fonts, extraction, tags, and target readers. |
| Measure delivery | Define what a non-owner browser event does and does not prove. | Use the portal's evidence, if any; possession of a file is not proof of reading. |
| Revoke access | Remove or restrict the hosted object subject to caches and policy. | A downloaded copy generally cannot be recalled by deleting the original link. |
The strongest reversal condition is recipient workflow. If the recipient's procurement portal accepts only PDF, HTML's runtime advantages do not satisfy the task. If a required calculator or prototype becomes static images in PDF, PDF's familiarity does not satisfy the task. Choose against the acceptance criteria, not the author's preferred tool.
Use HTML and PDF together without creating version confusion
For client, investor, teaching, and conference delivery, the resilient pattern is often:
- publish the HTML deck as the primary interactive experience;
- export a PDF from the same approved source and commit or store its release identity;
- link the PDF beside the HTML reader as a download/print fallback;
- label which format is authoritative for updates;
- update both from the same source when the content changes; and
- retire or mark superseded snapshots according to the delivery policy.
Do not claim that two formats are “the same deck” merely because they share text. Verify the behaviors and pages that matter. Record known differences such as hidden click steps, video poster frames, animation end states, live data timestamps, speaker notes, or inaccessible controls.
If the live URL can change content while the PDF is a fixed approval record, say so in the handoff:
The HTML link is the current interactive version. The attached PDF is the reviewed snapshot dated 2026-08-25. Interactive controls and live updates are available only in HTML.
Verify either format before sharing
HTML release checks
- Record the final HTML or bundle hash and framework version.
- Test the built output under local HTTP, not only a development server.
- Verify slides, keys, touch, focus, media, links, fonts, and required network requests.
- Publish the exact inspected artifact.
- Open the returned reader in a clean desktop and narrow mobile session.
- Confirm visibility and access policy separately from rendering.
Use the downloadable HTML presentation preflight checklist for a complete pass/fail record.
PDF release checks
- Export from the approved source with deliberate print/page rules.
- Confirm expected pages, size, orientation, margins, and hidden/revealed states.
- Search and extract text; inspect title, language, tags, reading order, links, and alternatives.
- Open the file in the recipient's expected reader, not only the exporting browser.
- Record the PDF hash and approved date.
- State whether the PDF or the live link owns future updates.
A valid export is not proof of successful delivery. A reader URL returning HTTP 200 is not proof that a recipient understood the content. Keep artifact QA, access, delivery, and business outcome as separate evidence.
What the benchmark does not prove
The benchmark covers one three-slide, zero-dependency source, Chrome 151.0.7922.174, a Playwright
keyboard/click sequence, and one generated PDF inspected with pdfinfo and pdftotext. The PDF
contains three 16:9 pages, extractable text, tags reported by pdfinfo, no form, and no embedded PDF
JavaScript.
It does not measure pixel parity, color accuracy, performance, file-transfer time, every PDF reader, every framework exporter, assistive-technology behavior, formal accessibility conformance, access control, audience engagement, or commercial value. PDF metadata contains a creation time, so a regenerated export can have a different hash even when visible content is unchanged.
No public deck was created and no synthetic production viewer event was generated for this test. The source and PDF are static evidence files on the product domain.
Frequently asked questions
Is an HTML presentation better than a PDF?
Only when live browser behavior or one current hosted link is part of the recipient task. PDF is better when fixed pages, print, a downloadable approval record, or a file-only intake process is the requirement. For important external delivery, a verified HTML link plus PDF fallback is often safer.
Does exporting to PDF preserve HTML animations and buttons?
Not in the conventional static export tested here. The PDF preserved three page renders and text, but it did not contain the HTML JavaScript runtime or the button state transition. Frameworks may offer options for revealing click steps as separate pages; test the exact exporter and output.
Can a PDF presentation still be accessible?
Yes, but accessibility must be authored and verified for the PDF representation. Tags, reading
order, document language, headings, alternative text, links, contrast, and keyboard/reader behavior
all matter. A metadata field such as Tagged: yes is not sufficient proof of conformance.
Can an HTML presentation work offline?
Yes, if the downloaded artifact contains every required runtime and asset and does not depend on network APIs. A self-contained HTML file and a complete local bundle can both work offline. A hosted URL alone is not offline delivery.
Is a PDF more secure than HTML?
The formats have different execution and parser risks, but neither creates access control. Treat uploaded HTML as executable content and isolate it. Deliver sensitive PDFs through an authorized system, and remember that deleting a shared link does not recall copies already downloaded.
Does a presentation view prove that the recipient read it?
No. A qualifying browser open proves only the event defined by the measurement system; a PDF download proves only a transfer. Neither proves attention, comprehension, approval, or business value without additional evidence.
Which format should an AI agent produce?
Give the agent the delivery contract. Ask for HTML when required behaviors must run in a browser; ask for PDF when pages must be fixed or accepted by a file-only workflow. For both, require exact artifact identity, a verification checklist, known differences, and a stop rule for failed checks.
Continue with the Quickstart or browse all HTML presentation publishing guides.