Free HTML to PDF Converter

A Short History of PDF

PDF began as John Warnock's "Camelot" project at Adobe in 1991: an internal proposal to create a "common file format that could capture documents from any application, send electronic versions of these documents anywhere, and view and print them on any machine." Warnock was Adobe's co-founder and the inventor (with Charles Geschke) of PostScript; the goal of Camelot was to take PostScript's print-fidelity guarantees and make them work on screen as well as paper. Acrobat 1.0 and PDF 1.0 launched in June 1993, with the first commercial Acrobat reader at $50. PDF was an Adobe-controlled proprietary format for fifteen years; Adobe released the spec to ISO in 2008 as ISO 32000-1:2008 (PDF 1.7 published as an open standard); the major PDF 2.0 (ISO 32000-2) arrived in 2017 with revisions through 2020. Adobe waived its remaining patent rights in April 2023, making PDF fully patent-free worldwide. PDF is now the universal portable document format, every operating system reads it natively, every printer understands it, every legal system accepts it. The whole edifice rests on PostScript-style fixed-position layout: each element on a PDF page has an absolute (x, y) position, baseline-aligned to the page coordinate system, with text encoded as font + glyph references and graphics as path commands.

The basic mismatch between HTML and PDF is what makes HTML-to-PDF conversion harder than it looks. HTML is reflow-based: content adapts to the viewport, paragraphs rewrap on resize, layout changes when the user zooms. PDF is fixed-layout: every element is positioned absolutely, page boundaries are explicit, no reflow ever happens. Converting from one to the other forces a series of hard decisions: how to break long pages, where embedded fonts live in the resulting PDF, how vector graphics are preserved, whether links remain clickable. There's no objectively right answer to most of these, the right behaviour depends on the use case.

Two JavaScript Approaches: Raster vs Vector

Browser-based HTML-to-PDF conversion has two architectures. html2pdf.js (Erik Koopmans, used by this tool) wraps two underlying libraries, html2canvas (which renders an HTML element to a canvas image by reading layout from the DOM and re-drawing it) and jsPDF (which builds a PDF from primitives). The pipeline: HTML → canvas image → embed image in PDF. The result is pixel-accurate: what you see in the preview is what you get in the PDF, but raster-only: the text in the PDF is an image, not selectable text. You can't search for words inside the PDF, you can't copy-paste from it, screen readers can't read it. For reports, certificates, invoices and one-shot documents this is acceptable; for documents where the text needs to be searchable or accessible, this is a significant limitation. The alternative architecture uses jsPDF directly with text-rendering primitives (doc.text(), doc.line(), doc.image()), building the PDF from scratch with selectable text and vector graphics. This requires writing converter code for every HTML element you want to support, but produces a "real" PDF that's searchable and accessible. The trade-off: html2pdf.js is one line of code; the jsPDF-direct approach is a substantial engineering project. This tool prioritises ease-of-use (html2pdf.js) over text selectability, be aware of the trade-off when deciding whether the output meets your needs.

Server-Side Alternatives, When Browser-Side Isn't Enough

wkhtmltopdf was the long-standing open-source HTML-to-PDF command-line tool, a WebKit-based renderer that converted HTML to PDF on the server. Used in countless CI pipelines, enterprise applications and PDF generation services. The wkhtmltopdf project was archived in 2023 (the GitHub repository is now read-only); it shouldn't be the recommendation for new applications, though billions of existing PDFs were generated with it. Puppeteer (Google, headless Chrome since 2017) is the modern industry standard for server-side HTML-to-PDF. Puppeteer's page.pdf() uses Chromium's full PDF generation pipeline, selectable text, embedded fonts, vector graphics, hyperlinks all work correctly because Chromium has a real PDF backend. Playwright (Microsoft, 2020) is the cross-browser equivalent (Chromium, Firefox, WebKit) with the same PDF generation capability. Prince (commercial, $495/server) is the best-in-class CSS Paged Media implementation, supports multi-column layouts, running headers/footers, named pages, footnotes, OpenType features. WeasyPrint (open source, Python) is the cross-platform alternative with similar features. Paged.js is a polyfill that brings CSS Paged Media features to browser-based PDF generation. The browser's built-in "Save as PDF" (File → Print → Save as PDF) is the cheapest option of all, it's free, already installed, supports CSS Paged Media reasonably well, and produces selectable-text PDF output. For one-off conversions, this is often the right answer rather than a third-party tool.

CSS Paged Media, How Real Print-from-CSS Works

The W3C's CSS Paged Media Module defines a set of CSS features specifically for paginated output: @page rules to control page size, margins and orientation; @page :left / @page :right for asymmetric margins on left and right pages of a book; @page :first for special handling of the first page; margin boxes (@top-center, @bottom-right, etc.) for running headers and footers; page-break-before / page-break-after / page-break-inside for controlling where pages break (with the modern syntax break-before: page / break-after: page / break-inside: avoid); orphans and widows for paragraph break control. Browsers implement varying subsets of CSS Paged Media in their print pipeline. Prince and WeasyPrint implement the full spec; Chrome's page.pdf() covers most of it; html2pdf.js (this tool) supports basic page-break-* rules but skips the more elaborate margin-box and named-page features. For documents that need book-quality layout (title pages, chapter starts, running headers, footnotes), use Prince or WeasyPrint; for the typical "save this report as PDF" case, html2pdf.js is sufficient.

Common Use Cases

• Invoices and receipts. The most common business case, a structured HTML template populated with order data, exported as PDF for emailing or archival. The text-not-selectable limitation rarely matters because the recipient doesn't need to search a single invoice's contents.
• Reports and documents. Quarterly business reports, project deliverables, internal status documents, generated from a templating system, exported as PDF for distribution.
• Certificates. Course completion certificates, conference attendance certificates, achievement badges, typically a single page with HTML/CSS styling, exported as a one-off PDF.
• Resumes and CVs. Candidates building their resume in a web template (Notion-export, custom builder) and exporting as PDF for submission. Text-selectability matters here because hiring software (ATS) often does keyword extraction from resume PDFs.
• Tickets and confirmations. Concert tickets, flight boarding passes, hotel confirmations, exported from web booking flows for offline storage or printing.
• Web content archival. Saving an article, blog post or documentation page as a fixed-format PDF for offline reference or long-term storage.
• Email-to-PDF. Converting HTML emails (newsletters, announcements) to PDF for forwarding or compliance archives.

Honest Scope: What This Tool Does and Doesn't

This tool uses html2pdf.js v0.10.1 (the bundled build with html2canvas + jsPDF) to render HTML in your browser and produce a PDF download. The resulting PDF is pixel-accurate to the preview: what you see is what you get, but the text is rendered as a raster image, not selectable text. It supports A4, Letter, A3 and A5 page sizes, portrait and landscape orientations, configurable margins, custom filename, and basic CSS page-break-* rules for page-break control. What this tool does not do, and where you should reach for an alternative: selectable / searchable text in the PDF (use Puppeteer server-side, or browser "Save as PDF"); book-quality layout with running headers, footers, named pages, footnotes (use Prince or WeasyPrint server-side); JavaScript execution in the rendered HTML (the converter runs the HTML through html2canvas which doesn't execute scripts inside the rendered content); animated content (PDF is static); media queries that depend on print contexts (the rendering happens in screen context). For everyday "make a PDF from this HTML" needs, html2pdf.js is good enough; for production-grade pipelines that need real PDF text and accessible output, server-side Puppeteer is the modern standard.

Privacy: Why Browser-Only Matters Here

PDF generation is a common cloud-SaaS business, services like DocRaptor, PDFShift, PDFCrowd, API2PDF charge per PDF generated, usually because they're running headless Puppeteer on a server farm and absorbing the cost of GPU-accelerated rendering. The trade-off is that the HTML you submit to those services is processed on their infrastructure: invoices contain customer information, reports contain business data, certificates contain personal names, resumes contain everything. Whatever you generate, the third-party service sees. This tool runs entirely in your browser via html2pdf.js, verify in DevTools' Network tab while you click Generate (the only outbound request is fetching the html2pdf.js library from the CDN; once loaded, no further requests). Take the page offline (airplane mode) after the library loads and the converter still works. Safe for HTML containing customer names, financial data, internal templates or any content you wouldn't want copied onto a stranger's hard drive.

Frequently Asked Questions

What HTML/CSS features are supported?

Standard HTML and CSS works: layouts (flexbox, grid), fonts, colours, backgrounds, borders, images, tables, transforms. Limited or unsupported: CSS animations and transitions (PDF is static), JavaScript execution inside the rendered HTML, media queries that depend on print context (the renderer uses screen context), CSS Paged Media features beyond basic page-break-* (no margin boxes, no named pages, no footnotes), some CSS filters and complex blend modes. For best results, use inline CSS or <style> tags rather than external stylesheets, html2canvas can't fetch external resources reliably.

How do I include images in my HTML?

Two reliable patterns. Data URIs: encode the image as Base64 and inline it directly in the HTML, <img src="data:image/png;base64,..." />: works regardless of network state. External URLs with CORS: external image URLs work if the image server returns the appropriate Access-Control-Allow-Origin header; without CORS support, html2canvas can't read the pixel data and the image will be missing from the PDF. For invoices and certificates that need a logo, Base64-encoded images are the safest bet, bundle the image with the HTML and you don't have to worry about network access.

Why isn't the text selectable in the PDF?

Because html2pdf.js renders the HTML to a canvas image first, then embeds the image in the PDF. The PDF's "text" is actually a raster image of text, not real text glyphs. This is the trade-off for visual fidelity: the PDF looks exactly like the browser preview, but you can't search, copy, or use a screen reader on it. For real selectable PDF text, the alternatives are: use the browser's built-in "Save as PDF" (File → Print → Save as PDF, produces selectable text and is free); use a server-side tool like Puppeteer's page.pdf() which has Chromium's full PDF generation pipeline; or write JavaScript that calls jsPDF's doc.text() primitives directly (substantially more work).

Why does my preview look different from the PDF?

The preview shows your HTML rendered live in the browser at screen size; the PDF is rendered at the chosen page size (A4, Letter etc.), which has different proportions. Some CSS features render slightly differently when the renderer captures to canvas, particularly fixed-position elements, complex transforms, and elements with overflow. The fix: test complex layouts before generating the final PDF, adjust margins or font sizes if needed, and consider switching to a server-side Puppeteer pipeline for documents where exact fidelity matters.

Can I add page breaks in my HTML?

Yes, use CSS page break properties on any element: page-break-before: always; (legacy syntax) or the modern break-before: page; to start a new page before the element. Same with page-break-after / break-after, and page-break-inside: avoid; / break-inside: avoid; to prevent an element being split across pages. html2pdf.js supports the basic page-break properties; the more elaborate CSS Paged Media features (margin boxes for headers/footers, named pages) need a more sophisticated converter like WeasyPrint or Prince.

Is my HTML uploaded to a server?

No. The HTML you paste and the PDF generated both stay in your browser. The only network request is for the html2pdf.js library itself loaded from a public CDN at page-load time; once loaded, no further outbound requests. Verify in DevTools' Network tab while you click Generate, or take the page offline (airplane mode) after the library loads and the converter still works. Safe for HTML containing customer data, financial details, internal business templates, or any content you wouldn't want a third-party PDF service to see.