Migrating off html2canvas and jsPDF, and getting real text back

What ports and what does not

The markup ports and the CSS mostly ports, with an important caveat: html2canvas reimplemented rendering rather than using the browser's, so it supported a subset and your templates were written inside it. What does not port is the entire approach. The old output was a picture of a page. There was no selectable text, no searchable content, no real pagination, and file sizes were driven by image resolution rather than by content. Everything downstream that treats the file as a document rather than as an image is newly possible and newly your responsibility.

What the call becomes

The canvas capture, the image conversion and the addImage call all disappear. The document becomes a POST to /v1/pdf with html, which also means the render moves off the client and onto a server, and that is a larger architectural change than the call itself. Anything that depended on the document being produced in the user's browser, including access to logged-in state, local component state and anything not reachable from a URL, needs the data assembled server side instead.

Side by side

The old shape and the new one, with the parts that have no counterpart called out in comments rather than quietly omitted.

// Before: a picture of the DOM, embedded in a PDF.
const canvas = await html2canvas(document.querySelector("#invoice"), { scale: 2 });
const img = canvas.toDataURL("image/png");
const doc = new jsPDF({ unit: "mm", format: "a4" });
doc.addImage(img, "PNG", 0, 0, 210, 297);
doc.save("invoice.pdf");

// After: the markup is rendered as a document, server side.
const res = await fetch("/api/invoice/1/pdf");   // your endpoint
// ...which calls:
const pdf = await fetch("https://api.pdfpipe.xyz/v1/pdf", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.PDFPIPE_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    html: renderInvoiceHtml(invoice),   // the same markup, built on the server
    filename: "invoice.pdf",
    options: { format: "A4" },
  }),
});

/* What changes beyond the call:
     the text is text: selectable, searchable, extractable
     the document paginates instead of being one tall image cut up
     file size is driven by content rather than by capture resolution
     the render needs the data, not the logged-in browser session   */

The CSS delta, in both directions

What the old engine accepted that a current one does not, and what it refused that a current one wants. The second direction is the one people forget, and it is where the value of the migration is.

• html2canvas supported a subset of CSS and approximated the rest, so a great deal starts rendering correctly for the first time. Shadows, filters, transforms and newer layout that were approximated or dropped now apply properly.
• Anything tuned to look right through html2canvas's approximation will look different, because it was compensating for a renderer that no longer sits in the path.
• Page breaks become real. The old approach either produced one enormous page or sliced a tall image at fixed intervals, so the templates contain no break rules at all and every one of them has to be added.
• Fonts become embedded rather than rasterised, so text is crisp at any zoom and the file no longer carries a high resolution bitmap of it.

What changes without anything erroring

The dangerous list. Each of these produces a different document and no diagnostic, so none of them are caught by a test that only checks the render succeeded.

• The document becomes multiple pages where it was one image, or paginates at different points than the fixed slicing did.
• File size usually falls substantially, which is a change worth expecting rather than being surprised by.
• Anything that relied on the capture scale for legibility, since text is now vector and the scale option no longer exists.
• Content that was only present in the browser, which is the architectural half of this migration and the part that is not about CSS at all.

What to diff before cutting over

Do not diff visually first: the outputs are different kinds of object and a pixel comparison will tell you nothing useful. Extract the text from the new output and confirm it contains what the document is supposed to say, which is a check the old pipeline could never pass. Then look at pagination, because that is genuinely new behaviour rather than changed behaviour.

The one thing that always breaks

Pagination. The old pipeline had none: it captured an element and put the picture on a page, so the templates have no break rules, no repeating table headers and no notion of a page boundary at all. The first real render puts a page break through the middle of a table row, and every long document needs its break behaviour written from scratch.

Frequently asked

Other migrations

The nearest neighbours first, then others that started from the same kind of tool, because the model matters more than the language.