How to convert a web page to PDF (and keep a dated copy)

There are four honest ways to convert a web page to PDF: the browser's print dialog, a desktop or command-line tool, a headless browser script you run yourself, and a rendering API. Each one is the right answer for a different job, and picking the wrong one is how a five-minute task turns into a weekend. This guide compares all four, plainly, and then covers the part almost every guide skips: how to keep a dated copy that still means something when someone asks, months later, what the page actually said.

That second part matters more than it sounds. A PDF with no capture date, no source URL, and no story about how it was made is just a picture of a claim. A PDF with all three is a record. If the pages you save might ever be shown to a customer, an auditor, or a lawyer, read to the end.

Method 1: the print dialog (Ctrl+P)

Every browser can convert a web page to PDF from the print dialog: press Ctrl+P (Cmd+P on a Mac), pick "Save as PDF" as the destination, adjust margins and scale, save. For a one-off page this is genuinely the best tool, and no software vendor should tell you otherwise.

Its limits show up fast, though:

• Sticky navigation bars and cookie banners print on top of the content, sometimes on every page.
• Sites with a print stylesheet may render something very different from what you saw on screen; sites without one often break at page boundaries.
• Backgrounds are stripped by default, so dark-themed pages come out as white voids unless you toggle "background graphics".
• It is manual. Ctrl+P works once. It does not work 4,000 times a month, and it cannot run at 3 a.m. when your report job fires.

We keep a longer checklist of these print-dialog fixes on our save webpage as PDF page if a one-off capture is all you need today.

Method 2: desktop apps and command-line tools

The next step up is a tool built for the job: a desktop converter, a browser extension, or a command-line binary like wkhtmltopdf. These add batch conversion, some layout control, and repeatability. The catch is engine quality. Many of these tools ride on old rendering engines; wkhtmltopdf in particular is frozen on a WebKit build from years ago and is no longer maintained, so modern CSS layouts (grid, newer flexbox behavior) come out subtly or dramatically wrong, and JavaScript-heavy pages often render before their content loads. If the page was built this decade, verify the output carefully before trusting the tool with anything important.

Method 3: script a headless browser yourself

For developers, Puppeteer or Playwright will convert a web page to PDF with full fidelity, because it is literally Chrome doing the printing. Ten lines of Node: launch the browser, open the URL, wait for the network to go idle, call the PDF function. For a personal script that runs occasionally, this is a fine and free answer.

Running it in production is a different sport. You now own browser memory leaks, Docker images missing font packages (CJK text and emoji silently become boxes), render drift every time Chromium ships a new version, and the queueing needed to stop ten concurrent renders from eating a server. We wrote a full cost breakdown in HTML to PDF library vs API; the short version is that the script is free and the fleet around it is not.

Method 4: a rendering API

A URL to PDF API moves the whole problem server-side: you send a URL or raw HTML plus options (page size, margins, wait-for-selector), and get back a finished PDF. The provider owns the browsers, the fonts, the patching, and the scaling. This is the right shape once conversion is a product feature rather than a chore: invoices on demand, nightly report exports, archiving a set of pages on a schedule.

Choosing: a quick comparison

Method	Best for	Fidelity	Automatable	Proves what the page said
Print dialog	One page, right now	Varies by site	No	Weak
Desktop / CLI tool	Small batches, simple pages	Poor on modern CSS	Partly	Weak
Headless browser script	Developers, low volume	Excellent	Yes, with ops work	Only what you build
Rendering API	Product features, recurring jobs	Excellent	Yes	Depends on the provider

The part everyone skips: why the dated copy matters

Here is a scenario every operations person eventually lives. A customer disputes a charge and claims your pricing page said something different in March. A regulator asks what your terms displayed on the date a user signed up. A partner insists a spec page changed after the contract. Web pages are the least stable documents your business relies on: they change silently, constantly, and without any record on your side.

The PDF you saved only helps if it can answer three questions:

• When was this captured? "Some time last spring, probably" does not survive a dispute. You want a timestamp recorded by the capture system itself, not a guess from a file's modified date, which changes every time the file is copied.
• What exactly was captured? The full URL, and ideally the source content as fetched, not just the rendered picture of it.
• Could it have been altered since? A PDF sitting in a shared drive can be edited by anyone with access. A copy held in a system with integrity checks (a content hash computed at capture time) is a different class of evidence. Courts authenticate web evidence by asking exactly these questions; our post on website archiving for compliance goes deep on what makes a snapshot defensible.

Manual methods fail all three quietly. The print dialog stamps a date in the footer only if you leave headers on, files get renamed and re-saved, and six months later nobody remembers which copy of "pricing-final-v2.pdf" was the original. If the pages matter, the capture process needs to record its own metadata, every time, without a human remembering to do it.

A practical setup for dated copies

Whatever tooling you choose, a defensible habit looks like this: capture on a schedule rather than on memory, so the record exists before anyone needs it; store the capture timestamp and source URL with the document, in the system, not in a filename; keep the copies somewhere with restricted write access; and check occasionally that old captures still open and still match their hashes. For anything ongoing, monthly snapshots of your own pricing, terms, and key product pages cost almost nothing and end arguments before they start. Our website archiving page covers retention schedules and retrieval in more detail.

Where Sitepdf fits

Sitepdf is the tool we are building because we kept gluing these two jobs together by hand: it is an HTML to PDF API that archives every page it renders. One call converts the page and stores a timestamped snapshot you can retrieve later, so the document and the dated copy come from the same request. It is in early access right now, meaning the API is not live yet and we will not pretend it is. What you can use today, free and without signing up, is the in-browser converter on our web page to PDF page, which turns pasted HTML into a real downloadable PDF entirely in your browser. If the render-plus-record workflow is the one you need, how it works shows the planned three-step flow, and early access locks in launch pricing when the API opens up.