HTML to PDF
Convert HTML files (.html, .htm) — saved web pages, email templates, design previews, dashboard exports — into a PDF document. Choose whether to include backgrounds. Files are processed in your browser.
HTML to PDF converts .html and .htm files into a PDF document. We sanitise the HTML (stripping <script> tags and inline event handlers), render it in a hidden container, capture the result with html2canvas at 2× DPI, and embed the pages into a PDF using pdf-lib. The Include backgrounds toggle mirrors your browser's print dialog convention — off by default for cleaner, paper-friendly output.
What is HTML to PDF?
HTML — HyperText Markup Language — is the foundation of every web page. Browsers render HTML by combining the markup with CSS for styling and (usually) JavaScript for interactivity. When you save a web page from your browser, you get an .html file that captures the markup; when you receive an HTML email template from a designer, that's an .html file too. HTML files are also produced by Mailchimp / SendGrid email exports, by web-application dashboards (Tableau, Looker), by static-site generators, and by anyone writing email templates or marketing landing pages.
Converting HTML to PDF is common when you need to share rendered output — an email proof, a dashboard snapshot, a saved article, a landing page mockup — with someone who isn't going to open it in a browser. PDFs are the universal print/share format. Most online HTML-to-PDF tools upload your file to a remote server, which is awkward when the HTML contains email addresses, internal links, or unreleased designs. This tool renders entirely in your browser; the HTML never crosses the network.
How does the in-browser HTML conversion work?
Pikowl reads each HTML file via the Blob.text() API, parses the markup with DOMParser, sanitises it (removing <script> elements and inline on* event handlers — JavaScript is never executed), and renders it inside a hidden styled container. html2canvas captures the rendered DOM as a 2× DPI image, sliced into page-height chunks and embedded into a PDF using pdf-lib. Inline CSS — <style> tags and style="..." attributes — is preserved. External resources (CDN-hosted images, web fonts) only load if they're same-origin or use CORS-enabled headers.
Is it safe to convert untrusted HTML files here?
Yes. We strip <script> tags and inline event handlers (onclick, onload, etc.) before rendering, so JavaScript inside the HTML never executes — even if you drag in a malicious file. javascript: URLs in href attributes are also stripped. Standard CSS, including external stylesheets and web fonts, is preserved (those load from their original origins, but no inline JS runs). The HTML is read locally via the File API, processed in your browser, and the PDF lives only in memory until download. Closing the tab discards everything.
What about "Include backgrounds"?
By default, page background colours and background images are not rendered into the PDF — the output uses a clean white background. This mirrors the convention in browser print dialogs (Chrome's "Background graphics" toggle, Firefox's "Print backgrounds") where the default is off because backgrounds consume printer ink and obscure text on dark themes. Enable Include backgrounds if your HTML's design uses backgrounds intentionally — email templates, marketing landing pages, dashboards with themed cards. The toggle controls only the page-level background; element-level background-color and background-image on individual divs are always rendered.
What are the limits and why?
Up to 30 HTML files per conversion, 10 MB per file, with a soft warning at 100 MB combined and a hard cap at 150 MB. The file count is lower than for TXT or Markdown (50) because HTML rendering is the heaviest step in this batch — html2canvas can take several seconds per long document, and the rasterisation produces large in-memory canvases. For very long single files (over ~50 PDF pages), expect a noticeable wait.
How does Pikowl compare to Smallpdf and iLovePDF for HTML?
The substantive differences are processing location, JavaScript handling, daily-use limits, and pricing. Numbers below reflect the public free-tier offers from each service as of April 2026.
| Feature | Pikowl | Smallpdf | iLovePDF |
|---|---|---|---|
| Where files are processed | Your browser | Remote server | Remote server |
| Sign-up required | No | Optional | Optional |
| Output options | Backgrounds toggle · 3 page sizes · page numbers | URL only (no .html files) | URL or .html, server-rendered |
| Max file size (free) | 10 MB | 5 MB | 200 MB (combined) |
| Price | Free | $9/mo for unlimited | $7/mo for premium |
Sources: smallpdf.com/pricing and ilovepdf.com/pricing, retrieved April 2026.
Common Uses
- Saved web pages: Convert browser-saved .html files of articles or research into a paginated, archival PDF for offline reading.
- Email template proofs: Designers and marketers can export an HTML email template as a PDF proof for client review without forwarding the actual email.
- Dashboard exports: BI tools (Tableau, Looker, Metabase) often offer HTML dashboard exports — convert those to PDF for inclusion in board decks.
- Landing page mockups: Convert a static-site landing page into a PDF for stakeholder review or feedback rounds.
- Form receipts and confirmations: HTML order confirmations and receipts saved from web forms become PDFs ready for accounting attachments.
- Online documentation snapshots: Save a documentation page (Stripe API docs, AWS console reference) as PDF for offline reference.
FAQ
Will JavaScript in the HTML run during conversion?
No. We strip <script> tags and inline event handlers (onclick, onload, etc.) before rendering, so any JavaScript in the file is removed. <a href="javascript:..."> URLs are also stripped. This means dynamic content that depends on JS (e.g. charts that render via Chart.js, lazy-loaded images) won't appear in the PDF. For JS-rendered content, render the page in your browser first and use a screenshot tool, or use the page's static export option if available.
Will external images and fonts load?
Only if the resources are same-origin or served with CORS-enabled headers. Most CDN-hosted web fonts (Google Fonts, Adobe Fonts) and images set CORS, so they typically load correctly. Same-domain resources work fine. Cross-origin resources without CORS headers will fail to load and appear blank in the PDF. To guarantee everything loads, embed images as data URIs (data:image/png;base64,...) before converting.
Should I turn on "Include backgrounds"?
Default is off, matching browser print dialogs. Turn it on when the HTML's design uses page-level backgrounds intentionally — themed email templates, marketing landing pages, dark-mode dashboards. Leave it off for content where backgrounds would just consume printer ink (articles, documentation, code listings).
Is the text in the resulting PDF selectable?
No — the html2canvas pipeline rasterises the rendered HTML, so the resulting PDF pages are images. Text is not selectable, searchable, or accessible to screen readers. This is the trade-off for full styling fidelity. For selectable text from documents, use TXT to PDF (plain text input) or save the HTML's text content separately and convert that.
How does multi-page output work?
Long HTML content is rendered as a single tall canvas, then sliced into page-height chunks. Each chunk becomes one PDF page. Slicing happens at the canvas pixel boundary, which means content can split mid-paragraph or mid-image at the page break. CSS @page rules and page-break-inside: avoid are not respected — that's a browser-print-engine feature we'd need a different rendering library to support.
Are HTML files uploaded to a server?
No. The conversion runs entirely in your browser — open DevTools' network tab and you'll see the html2canvas chunk download once on first use, plus any external resources (images, fonts) that the HTML itself references. The HTML file content is never sent to a Pikowl server.
Why is the file count limit lower than TXT or Markdown?
HTML rendering is the heaviest step. html2canvas walks the entire DOM, computes styles for every element, downloads external resources, and rasterises everything to a single canvas. For complex pages this takes several seconds per file and consumes significant memory during the process. The 30-file limit (vs. 50 for TXT/MD) keeps batch conversions manageable on mobile devices.
By the Numbers
- HTML5 became a W3C Recommendation in October 2014, marking the modern era of the format; the HTML Living Standard from WHATWG is now the authoritative version, evolving continuously.
- html2canvas (the rendering library this tool uses) is downloaded over 5 million times per week from npm, making it the de facto choice for in-browser DOM-to-image conversion across the web ecosystem.
- Browser print dialogs default "Background graphics" to off because page backgrounds consume printer ink and obscure text — Pikowl's HTML to PDF mirrors this convention, with the toggle available when you need full design fidelity.