Get started

PDF4.dev vs html2pdf.js

html2pdf.js takes screenshots of HTML and pastes them as images in a PDF. PDF4.dev renders HTML natively through Chromium, producing real text-based PDFs with vector graphics, selectable text, and clean page breaks.

Updated March 2026

This comparison is published by PDF4.dev. We aim for accuracy but acknowledge our perspective.

TL;DR

Choose PDF4.dev if you want

  • Native Chromium rendering with real vector text
  • A REST API for server-side PDF generation
  • A template editor your whole team can use
  • Selectable, searchable, accessible PDFs
  • Clean page breaks and full CSS support

Choose html2pdf.js if you want

  • Client-side only, no server needed
  • A quick prototype tool for simple outputs
  • Zero setup (one script tag)
  • But: screenshot-based with quality limitations (blurry text, no text selection, broken page breaks)

Feature-by-feature comparison

FeaturePDF4.devhtml2pdf.js
Rendering methodNative Chromiumhtml2canvas screenshots
Text qualityVector (scalable)Raster (bitmap)
Text selectableYesNo (image-based)
CSS supportFull (flexbox, grid)Partial (canvas limitations)
Page breaksNative paged mediaCanvas splitting (often cuts content)
Font renderingFull web fontshtml2canvas font issues
File sizeCompact (vector)Large (embedded images)
Cross-origin imagesHandledCORS issues
Server dependencyRequires serverBrowser-only
Setup complexityAPI key + POST requestScript tag + one function
Template editorCode + visual editorNone
Reusable componentsHeaders, footers, blocksNone
APIREST API with authNo API
Free PDF tools24 browser-based tools (compress, merge, split...)None
Batch generationCSV upload, variable mapping, ZIP downloadNone
AI agent supportBuilt-in MCP serverNone

The screenshot problem

html2pdf.js does not render PDFs. It takes a screenshot. The library works in three steps: html2canvas captures the DOM as a canvas bitmap, converts it to a JPEG or PNG image, then jsPDF embeds that image into a PDF page. The result is a PDF that contains a single flat image per page, not actual document content.

This approach causes several fundamental problems:

  • Text is not selectable: since the PDF contains images, users cannot copy text, search within the document, or use screen readers
  • Output is blurry when zoomed: bitmap images pixelate at higher zoom levels, unlike vector text which stays sharp at any scale
  • File sizes are large: embedding full-page images produces PDFs 5-10x larger than equivalent vector-based documents
  • Page breaks cut content randomly: html2pdf.js splits a single tall canvas into page-sized chunks, often cutting through lines of text, table rows, or images
  • Accessibility is zero: no document structure, no headings, no reading order, no alt text: the PDF is opaque to assistive technology
  • CSS rendering is incomplete: html2canvas does not support all CSS properties. Shadows, transforms, gradients, and some flexbox layouts may render incorrectly or not at all

PDF4.dev uses Chromium's native page.pdf() API, which produces real PDF content: vector text, embedded fonts, proper page breaks via CSS paged media, and full CSS support including flexbox, grid, and modern properties.

When html2pdf.js works

To be fair, html2pdf.js has valid use cases where its limitations are acceptable:

  • Quick prototypes where PDF quality does not matter
  • Internal tools where nobody needs to select or search text
  • Simple single-page documents without complex layouts
  • Situations where you absolutely cannot make server calls and need everything to run in the browser

But if you need professional-quality PDFs for invoices, contracts, reports, or any document that will be shared with customers or partners, screenshot-based rendering is not sufficient. Production documents need real vector text, clean page breaks, and accessible content.

Frequently asked questions

Useful resources

Other comparisons

Try real PDF rendering

Stop embedding screenshots. Generate real vector PDFs with selectable text, clean page breaks, and full CSS support.