Angular to PDF: Convert an Angular Component or HTML to a Real PDF

Search for "Angular to PDF" and nearly every tutorial hands you the same pair: jsPDF to build the file and html2canvas to capture the element. 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 html2canvas reads the DOM and paints your component onto a <canvas>, then jsPDF 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 long reports get sliced awkwardly across pages because the image is scaled to fit.

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". Angular Material components, which lean on modern CSS custom properties and layered styles, are also a common source of drift in the canvas snapshot. You can patch these by overriding colors 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 renderApplication from @angular/platform-server (the same server-side rendering Angular uses for SSR) and post that HTML instead.

import { renderApplication } from "@angular/platform-server";
import { bootstrapApplication } from "@angular/platform-browser";
import { InvoiceComponent } from "./invoice.component";

const html = await renderApplication(
  () => bootstrapApplication(InvoiceComponent),
  { document: "
" }
);

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 component styles, Angular Material theme, 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: renderApplication 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 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, structured document that looks nothing like any page in your app, a shipping label, a ticket, a one page certificate, then pdfmake is a reasonable fit and it costs nothing. You describe the document as a JSON structure of columns, tables and text, 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 in its own declarative format, and anything with real typography, nested tables or responsive design becomes tedious to express.

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

There is one thing no Angular 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 Vue 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.