← All posts

Website Page to PDF Converter: A Developer's Guide

September 20, 2026

What "Website Page to PDF Converter" Means for Developers

Search "convert webpage to PDF" and you'll find free browser extensions and online tools built for converting a single invoice or article by hand. That's not this article. For engineering teams, a website page to PDF converter is a service or pipeline that takes a URL — often behind a login, often rendered by React or Vue — and produces a print-faithful PDF on demand, at scale, without a human clicking "export."

That distinction matters because the problem is harder than it looks. A consumer tool assumes a static, publicly accessible page. Programmatic URL to PDF conversion has to deal with authentication cookies, client-side rendering that finishes loading well after the initial HTML response, custom fonts, and print layout rules most pages never define. Getting this right means either running an actual browser engine to render the page as a user would see it, or handing that job to a service that already does.

There are two practical paths: build and operate your own headless browser pipeline, or call a managed rendering API. The rest of this article walks through both, plus the failure modes that trip up teams regardless of which path they choose.

Why Legacy Tools Like wkhtmltopdf Fall Short

If you inherited a codebase from a few years ago, there's a decent chance it's calling wkhtmltopdf. It was the default html to pdf converter for a long time because it was free, fast, and simple to script. The problem is that it renders pages using an old WebKit build, not a modern browser engine — so it routinely mangles CSS Grid, flexbox, custom fonts, and any JavaScript-driven content. Its GitHub repository was archived in 2023, there's been no new release since, and it carries at least one unpatched CVE, as documented in this wkhtmltopdf alternatives migration guide. Running an unmaintained binary with a known vulnerability in a production pipeline is a hard sell to any security review — which is why most teams now treat wkhtmltopdf as a liability, and why the search for a wkhtmltopdf alternative almost always leads to real browser engines instead of another lightweight parser.

Two Ways to Convert a URL to PDF Programmatically

Once you rule out legacy renderers, the real decision is whether to run headless Chrome yourself or delegate the job to an API. Both approaches rely on the same underlying tech — a Chromium-based browser executing Chrome DevTools Protocol commands to print a rendered page — but they differ enormously in what you have to own.

Chrome's shift to --headless=new mode in 2023 made this decision easier: the new headless mode shares the same rendering code path as the visible desktop browser, so headless Chrome PDF generation now produces output that actually matches what you see in a normal browser window — something the old headless mode couldn't reliably promise.

Option 1: DIY With a Headless Browser

Puppeteer and Playwright both expose a straightforward page.pdf() call. A minimal example with Puppeteer:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com', { waitUntil: 'networkidle0' });
  await page.pdf({
    path: 'output.pdf',
    format: 'A4',
    printBackground: true,
  });
  await browser.close();
})();

That's the happy path. What it doesn't show is everything you now own: downloading and updating Chromium binaries, provisioning enough memory per concurrent render, handling crashed or hung browser processes, and patching for security advisories as new Chrome releases ship. The official Page.pdf() docs are worth reading closely — options like print media emulation and background graphics aren't always on by default. For the full cost breakdown in engineering time versus dollars, see Headless Chrome vs Managed Browser API: The Real Cost.

Option 2: A Managed Rendering API

The equivalent request against Browsevra's PDF endpoint looks like this:

curl -X POST https://api.browsevra.com/v1/pdf \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "format": "A4", "printBackground": true}' \
  --output output.pdf

One request, one response — no browser to launch, no binary to update, no crashed process to restart at 2 a.m. Infrastructure, scaling, and Chrome patching are handled behind the endpoint, which is the tradeoff most teams are actually weighing when they compare "build vs buy" for this problem.

Common Pitfalls When Converting Pages to PDF

Whichever path you pick, these issues show up in production regardless:

  • JavaScript not finished loading. Capturing the page before async data or images resolve produces blank sections. Wait on a network-idle or specific DOM signal, not a fixed timeout.
  • No print CSS. Browsers apply screen styles by default unless you define @media print rules, which is why headers, sidebars, and fixed navigation often bleed into a PDF never meant to be printed.
  • Page breaks cutting content mid-element. Long tables or cards get sliced across page boundaries without explicit break-inside: avoid rules.
  • Missing fonts or images. Custom web fonts and lazy-loaded images can fail to render if the renderer captures the page too early or blocks certain resource types.
  • No header/footer template. Puppeteer's page.pdf() supports headers and footers, but they require explicit HTML templates — they don't inherit your site's markup automatically.

These styling and pagination issues are worth solving properly rather than patching around — see HTML to PDF Print CSS: Fixing Breaks, Headers, Margins for a full treatment of an html to pdf converter for developers who need pixel-accurate output.

Choosing the Right Approach for Your Use Case

If you're generating a handful of PDFs a week for an internal tool, running Puppeteer locally or in a small container is fine — the operational overhead is minor. If PDF generation is customer-facing, runs at meaningful volume, or needs to stay reliable while you're focused on product work, the calculus changes: you're now on the hook for browser crashes, memory spikes under concurrency, and keeping pace with Chrome's release cycle. That's real, ongoing work, not a one-time setup cost — covered in more detail in the performance guide on blocking resources if you're set on the DIY route.

For most production use cases, skipping the browser-ops work is the pragmatic choice. Check the Browsevra docs for a quick-start on the PDF endpoint, and the pricing page to see the free tier and usage-based costs before committing. browsevra handles the rendering infrastructure so your team can ship the feature instead of maintaining a browser fleet.

Frequently Asked Questions

What's the best way to convert a website page to PDF using code instead of a browser extension?

Use a real browser engine — Puppeteer, Playwright, or a managed API built on Chromium — rather than a browser extension or lightweight HTML parser. Extensions require manual clicks and can't run unattended, while a scripted page.pdf() call or an API request can be triggered from your backend on any schedule or event.

Is wkhtmltopdf still safe to use for HTML-to-PDF conversion?

No — its GitHub repository was archived in 2023, there have been no new releases since, and it carries at least one unpatched CVE. It also renders with an outdated WebKit engine that struggles with modern CSS and JavaScript-heavy pages, making it a poor choice for both security and output quality.

Can I convert a PDF from a page that requires login or JavaScript rendering?

Yes, as long as the renderer can carry authentication (cookies, headers, or a logged-in session) and wait for client-side JavaScript to finish executing before capturing the page. Both Puppeteer/Playwright and managed APIs like Browsevra support passing auth context and waiting on network-idle signals for this reason.

What's the difference between Puppeteer and a managed PDF API?

Puppeteer is a library you run yourself, meaning you own the Chromium binaries, server memory, concurrency limits, and security patching. A managed API like Browsevra exposes the same underlying rendering capability over a single HTTP request, handling the infrastructure and scaling on its side.

Why does my generated PDF look different from what I see in the browser?

Usually because the page was captured before JavaScript finished rendering, or because your CSS doesn't define print-specific styles, so the browser falls back to screen layout rules that don't translate well to a printed page. Missing printBackground settings or unloaded custom fonts are also common culprits.

How do I handle page breaks and headers/footers when converting a page to PDF?

Control page breaks with CSS rules like break-inside: avoid on elements you don't want split across pages, and define explicit HTML templates for headers and footers since they aren't inherited automatically from your site's markup. Puppeteer's page.pdf() accepts dedicated header/footer template options for exactly this purpose.