React to PDF: Convert a React Component or Page to a Real PDF

The most common first attempt is react-to-pdf or a hand rolled html2canvas plus jsPDF combination. 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 these libraries paint the component onto a canvas and embed 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 it does not reflow, so a tall report becomes one enormous image awkwardly sliced across pages.

Then there is the CSS problem that arrived with Tailwind v4. Tailwind now emits colors in 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 the 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 renderToStaticMarkup from react-dom/server and post that HTML instead.

import { renderToStaticMarkup } from "react-dom/server";
import Invoice from "./Invoice";

const html = renderToStaticMarkup(<Invoice data={invoice} />);

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, CSS grid, web fonts and background colors all render the way they do on screen, and the resulting text is real, selectable and searchable. Our HTML to PDF in Node.js guide covers the same call from an Express or Next.js API 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 bespoke document that looks nothing like any page in your app, a shipping label, a certificate, a fixed format statement, then @react-pdf/renderer is a genuinely good fit and it costs nothing. You describe the document with its own <View> and <Text> primitives, and because it never touches a browser it is fast and has no infrastructure. The catch is exactly that separation: it ignores your existing CSS, so you are rebuilding the layout in a second styling system, and complex responsive designs are painful to express in its subset.

So the rule is simple. Reusing a page or a template your users already see, and you want it to match? Render it in a real browser. Building a brand new document layout from scratch in code, with no HTML to reuse? @react-pdf/renderer earns its place. The screenshot libraries 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 React 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, the Vue to PDF and Angular to PDF pages walk the same trade offs for the other big component frameworks, and if you are weighing running your own headless Chrome instead, the Puppeteer alternative page runs that trade off honestly. Renders are transient by default; leave archiving off and we return the PDF and store nothing.