HTML to PDF — Convert HTML Files to PDF Online
Convert an HTML file to a styled PDF. Headings, paragraphs, lists, links, and inline emphasis are preserved with semantic typography.
Drop your HTML / XHTML file hereTap to select a file
Supports HTML, XHTML, up to 50MB
What to do next
Related tools
Markdown to HTML
Convert Markdown text to HTML with live preview.
textHTML to Markdown
Convert HTML markup to clean Markdown text.
textText to PDF Converter
Convert a plain text file (.txt) to a properly formatted PDF document with automatic word wrap and page breaks.
pdfPDF to HTML
Convert a PDF document to HTML format.
pdfAbout HTML to PDF
HTML to PDF turns a self-contained .html or .htm file into a paginated PDF that preserves the document’s semantic structure: headings keep their hierarchy, paragraphs stay as paragraphs, ordered and unordered lists keep their numbering and bullets, blockquotes are visually offset, and inline emphasis (bold, italic, links) carries through. The conversion is built on top of the browser’s native DOMParser plus the open-source pdf-lib JavaScript library, which means the entire pipeline lives inside your tab — no server, no upload, no log line, no third-party script ever sees your document.
A deliberate design choice sets this tool apart from headless-Chromium-based converters: it is local-only by intent. The renderer never issues a network request to fetch a remote stylesheet, web font, image, or analytics pixel. Two consequences follow from that. First, the conversion is private — even an HTML file that originally pulled tracking pixels or analytics from a third party stops doing so the moment you convert it. Second, the result is deterministic — the same input always produces the same PDF because there is no live network state baked in.
The renderer focuses on semantic content, which is what 90% of HTML-to-PDF use cases actually need: an article export, a generated report, a static documentation page, a transactional email mocked up as HTML. Headings (h1 through h6) become a typographic scale that matches the visual hierarchy of the original page. Paragraphs flow naturally with line wrapping. Lists indent and number correctly even when nested several deep. Links are styled in a contrasting blue but the underlying URL is preserved as text rather than as a clickable hotspot — that keeps the PDF print-friendly and avoids ambiguity about where a link points when the document is read offline.
What the renderer does NOT do: reproduce CSS layout. Flexbox grids, multi-column layouts, custom font families, exact pixel positioning, and CSS animations are not supported because reproducing them faithfully requires a browser-class layout engine. That is the trade-off — server-side converters that DO reproduce CSS layout (Puppeteer, wkhtmltopdf) charge for compute time because they spin up a full headless Chromium for each conversion. If your HTML is a heavily designed marketing page where pixel-perfect layout matters, use one of those instead. If your HTML is content (an article, a report, an export, a documentation page), the semantic conversion this tool provides is what you actually want.
Scripts inside the HTML are stripped before parsing for safety. That means `<script>` blocks, inline event handlers, and `<iframe>` embeds are removed before the document tree is walked — no JavaScript from the input ever runs in your tab. The converter handles malformed HTML gracefully because DOMParser uses the same lenient HTML5 parser the browser uses for normal page loads. Files up to 50 MB are accepted, which is generous: even a long-form documentation export rarely exceeds 5 MB once stripped of base64-embedded images, and a typical article is tens of kilobytes. There is and the same code runs in every modern browser.
How it works
- 1Pick an .html, .htm, or .xhtml file from your device. The browser file picker filters to HTML by default.
- 2DOMParser reads the file using the same HTML5 parser the browser uses for normal page loads, so malformed input is handled forgivingly.
- 3Scripts, iframes, and external embeds are stripped; the document tree is walked into headings, paragraphs, lists, blockquotes, and code blocks.
- 4pdf-lib lays out the resulting block list onto A4 portrait pages with consistent typography and pagination.
- 5Click Download to save the PDF. The file you uploaded is never sent off-device, never written to disk, and never logged.
Common use cases
- Convert a generated report exported as HTML into a PDF for a stakeholder who cannot open the .html directly
- Snapshot a self-contained documentation page so a contractor has it offline before a site visit
- Turn a transactional-email HTML mockup into a PDF for a design review
- Archive a saved web-clip article as a clean PDF without the original page’s ads or trackers
- Convert a static blog export into a print-friendly PDF for a reading club
- Bundle a hand-coded HTML invoice into a PDF before sending to a client
FAQ
What HTML elements are preserved?
Headings (h1–h6), paragraphs, ordered and unordered lists, blockquotes, code blocks, horizontal rules, and inline emphasis (bold, italic, links). The renderer maps each element to a typographic style in the PDF.
Will it fetch external CSS, fonts, or images?
No. The converter is intentionally local-only — it reads the HTML you upload and never makes a network request to fetch remote stylesheets, web fonts, or images. That keeps your workflow private and the output deterministic.
Does it run JavaScript inside my HTML?
No. Scripts are stripped before parsing for safety. Only the static, server-rendered DOM produced by your HTML is converted to PDF.
Is the file uploaded?
No. Your .html or .htm file is read into memory by JavaScript running in your tab, parsed with the browser’s built-in DOMParser, and rendered to PDF by the open-source pdf-lib JavaScript library — entirely on your device.
What about full-fidelity CSS layout?
CSS layout (flex, grid, custom fonts, exact pixel positioning) is not reproduced — that requires headless-Chromium printing. This tool focuses on semantic content, which is what 90% of HTML-to-PDF use cases (reports, articles, exports) actually need.
Why does my PDF look simpler than the original web page?
The converter intentionally focuses on semantic content rather than CSS layout. Flex grids, custom fonts, and absolute-positioned elements are not reproduced because doing so would require running a full headless browser. What you get is a clean, semantically structured document that prints well and reads well — the trade-off most "save webpage as PDF" workflows actually want.
Can it fetch external CSS, fonts, or images at convert time?
No, by design. The converter never makes a network request to a third-party domain, even if your HTML references one. This keeps the workflow private (no leak to ad servers or CDNs) and the output deterministic (the same input always produces the same PDF). If you need an embedded image to appear in the result, inline it as a base64 data-URI before converting — though note this version focuses on text-only conversion.
Is it safe to convert HTML I downloaded from somewhere unknown?
Yes. The converter strips all script tags, inline event handlers, and iframe/object/embed elements before parsing the tree. No JavaScript from the input ever executes in your tab. The DOMParser instance creates a detached document that is never attached to the page DOM, so nothing in the input HTML can touch the rest of your tab.
Will my links be clickable in the PDF?
Links keep their text and are visually styled (a contrasting blue colour) but they are not active hyperlinks in this version. The URL is preserved in the rendered text where the anchor text appeared. This is a deliberate choice — most readers prefer the printed form where the destination URL is visible rather than hidden behind ambiguous anchor text.
What HTML elements survive the conversion?
Headings (h1–h6), paragraphs, blockquotes, ordered and unordered lists (including nested), `<pre>` and `<code>` blocks, horizontal rules, and inline `<strong>` / `<b>` / `<em>` / `<i>` / `<a>` tags. Tables are not yet rendered as bordered tables in this version (a future update will add that). Images, audio, video, and form elements are skipped.
Is this the same as printing to PDF from my browser?
Similar but more opinionated. Your browser’s built-in print-to-PDF runs the page’s full layout engine and respects all the CSS. This converter is faster, smaller, and produces a more uniform output (consistent typography across very different input pages), at the cost of not reproducing layout. Pick whichever matches your need: this for content, the browser print dialogue for layout fidelity.
What’s the maximum file size?
The uploader accepts HTML files up to 50 MB per run. That comfortably covers very long documentation exports and even articles with substantial inline base64 images, which is well above what any realistic single-page HTML document needs.
Does it handle non-Latin scripts?
Yes for any character that the standard PDF Helvetica encoding (WinAnsi) supports — that covers most western European languages plus many widely-used punctuation marks. Cyrillic, Greek, CJK, Arabic, and Hebrew characters cannot be embedded in the standard PDF fonts and will be replaced with empty cells; supporting those requires bundling additional Unicode fonts, which is on the roadmap.