Vue to PDF: Convert a Vue Component or HTML to a Real PDF

The usual first attempt is vue-html2pdf, which is a thin Vue wrapper around html2pdf.js, which itself chains html2canvas and jsPDF. It is appealing because it runs entirely in the browser and needs no backend. It also quietly produces a worse document than people expect. Under the hood it paints the component onto a canvas and embeds that canvas as an image, so the PDF is a picture of your UI. The text inside cannot be selected, copied or searched, it turns fuzzy the moment someone zooms in, and because html2pdf.js resizes the root element to fit a page, the internal content reflows and long reports get sliced awkwardly across pages.

Then there is the CSS problem that arrived with Tailwind v4. Tailwind now emits colors with the oklch() function, and html2canvas cannot parse it, so the capture fails with "Attempting to parse an unsupported color function oklch". You can patch it by overriding every color at render time, but that is a maintenance tax you pay forever. A real browser has none of these limits, because it is the same engine that drew the page in the first place.

The fix is to move rendering off the client and into a real browser. You have two clean ways to feed Sitepdf. If the document is a live route in your app, an invoice page, an order confirmation, a dashboard export, point the API at that URL and it loads the page in managed Chromium exactly as a visitor would, runs your JavaScript, waits for your charts, and returns the PDF. If you would rather not expose a route, render the component to an HTML string on the server with renderToString from @vue/server-renderer and post that HTML instead.

import { createSSRApp } from "vue";
import { renderToString } from "@vue/server-renderer";
import Invoice from "./Invoice.vue";

const app = createSSRApp(Invoice, { invoice });
const html = await renderToString(app);

const res = await fetch("https://api.sitepdf.com/v1/render", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.SITEPDF_KEY}` },
  body: new URLSearchParams({ html, format: "Letter", archive: "true" }),
});
const { pdf_url } = await res.json();

Either way the browser does the layout, so your Tailwind classes, scoped styles, CSS grid, web fonts and background colors all render the way they do on screen, and the resulting text is real, selectable and searchable. One thing to watch when you render to a string: renderToString gives you markup, not your bundled CSS, so inline the styles or link your stylesheet in the HTML you post. Our HTML to PDF in Node.js guide covers the same call from an Express or Nuxt server route, and the PDF generator API page has the full parameter list.

We are not going to pretend the API is always the answer. If your PDF is a short, fixed document that looks nothing like any page in your app, a shipping label, a ticket, a one page certificate, then plain jsPDF is a reasonable fit and it costs nothing. You position the text and boxes yourself, and because it never touches a browser it is fast and has no infrastructure. The catch is exactly that: it ignores your component CSS, so you are rebuilding the layout by hand, and anything with real typography, tables or responsive design becomes tedious to express in coordinates.

So the rule is simple. Building a brand new, short document layout from scratch, with no HTML worth reusing? jsPDF earns its place. Reusing a Vue page or template your users already see, and you want the PDF to match it? Render it in a real browser. The screenshot wrappers are the one option that rarely wins on a document that matters, because they trade away real text for convenience.

There is one thing no Vue library gives you, on the client or the server: a record. When you generate an invoice, a receipt or a signed quote, the file goes to the customer and nothing verifiable stays with you. Add archive=true to the render call and Sitepdf also stores a timestamped, immutable snapshot of exactly what it rendered, retrievable by id later. For finance, legal and compliance work that provenance is often the reason to render server side in the first place. The website archiving page explains how the record works, and the React to PDF and Angular to PDF pages walk the same trade offs for the other big component frameworks. Renders are transient by default; leave archiving off and we return the PDF and store nothing.