Next.js PDF Generator: Generate a PDF from HTML in Next.js

Almost every Next.js PDF tutorial starts with Puppeteer, and almost every one of them assumes a normal Node server. On Vercel and similar serverless hosts that assumption breaks. A serverless function has a hard size limit, and a full Chromium download is far larger, so npm install puppeteer and deploy simply fails to fit. The community workaround is puppeteer-core paired with @sparticuz/chromium, a Chromium build stripped down and compressed specifically to squeeze under the cap.

It can work, and for some teams it is worth it, but be clear eyed about the cost. You are now pinning two packages whose versions must stay compatible with each other and with the platform, every upgrade is a small risk, and each cold start has to decompress and boot Chromium, which adds noticeable latency to the first request after idle. Our Puppeteer PDF on AWS Lambda guide walks through this exact setup and its failure modes on Lambda, and the same constraints apply on Vercel functions.

The alternative is to never put a browser in your deploy at all. A rendering API runs managed Chromium on its own servers, so from Next.js it is a single request. This works identically on a Vercel function, the edge runtime, or a self-hosted Node server, because nothing about it depends on your runtime being able to launch a browser.

// app/api/pdf/route.ts
export async function POST(req: Request) {
  const { url } = await req.json();

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

  const { pdf_url } = await res.json();
  return Response.json({ pdf_url });
}

Point it at any route in your app, an invoice page, a receipt, a dashboard export, and Chromium loads that page exactly as a visitor would, runs your client JavaScript, waits for charts, and returns the PDF. If the document is a React component you would rather not expose as a route, render it to an HTML string on the server with renderToStaticMarkup and post the HTML instead, which the React to PDF page covers in full.

We will say plainly when you do not need us. If your Next.js app is deployed on a long lived Node server you control, a VPS, a container, a traditional host, then full puppeteer installs and runs without any size limit, and it is free. Run it yourself. The Puppeteer alternative page lays out that trade off honestly: self-hosting Chromium is the right call when you have somewhere to run it and someone to keep it patched and memory stable under load.

The API earns its place in two situations. The first is serverless, where the browser genuinely does not fit and every cold start costs you. The second is scale, where keeping a fleet of Chromium processes warm, patched and from leaking memory becomes real operational work you would rather not own. If neither applies to you, a local browser is a perfectly good Next.js PDF generator.

One capability no local approach offers is a record. When your Next.js app generates an invoice or a signed quote, the file ships to the customer and nothing verifiable stays behind. Add archive=true to the render call and Sitepdf stores a timestamped, immutable snapshot of exactly what it rendered, retrievable by id. For finance and compliance features that provenance is frequently the whole reason to render server side. The website archiving page explains the record, and the PDF generator API page has every parameter. Renders are transient by default; leave archiving off and we store nothing.