Webpage to PDF

Convert Web Page to PDF and Save Webpage as PDF with a Dated Copy

Print dialogs cut columns in half, drop backgrounds and leave a file nobody can date. SitePDF renders the page in real Chromium, waits for your content, returns a PDF that looks like the page and, in the same call, archives a timestamped copy you can pull up when someone asks what the page said.

PDF and archive in one call
Plans from $49 a month
Your HTML stays yours

Live demo

Runs in your browser. Nothing is uploaded. One PDF free to try, then a plan.

Sample Page size Orientation Margins

Your HTML

Live preview

Your PDF is downloading. That was the free one. The Starter plan converts as many as you need, for $49 a month or $288 a year, half price.

See the plan

Short answer

To convert a web page to PDF reliably, render it in a real browser engine, wait for the content to finish loading, print with page break rules, and store the capture time and source URL with the file. The print dialog (Ctrl+P) does the first part for one page. A rendering API does all four, unattended, at any volume. SitePDF is that API: one call returns the PDF and an archived snapshot, and the Starter plan covers 10,000 renders a month for $49.

Written and fact checked by the SitePDF team.

Four ways to convert a web page to PDF, compared

Each method is the right answer for a different job. The last column is the one teams forget until a customer, an auditor or a lawyer asks what the page showed on a given date.

Method	Best for	Fidelity on modern pages	Runs unattended	Proves what the page said
Print dialog (Ctrl+P)	One page, right now	Varies by site	No	Weak
Desktop app or CLI tool	Small batches of simple pages	Poor on modern CSS (wkhtmltopdf is unmaintained)	Partly	Weak
Your own headless browser script	Developers at low volume	Excellent	Yes, with ops work	Only what you build
Rendering API	Product features and recurring jobs	Excellent	Yes	With SitePDF, a dated archive entry per render

Headless script costs are broken down in HTML to PDF library vs API.

Why web page to PDF conversions go wrong

A web page is a living layout: responsive breakpoints, lazy loaded images, charts that draw after the data arrives, fonts that swap in late. Naive converters snapshot the page before it finishes becoming itself. That is how you get PDFs with empty chart boxes, fallback fonts and a cookie banner across the content.

The print dialog adds its own problems. Sticky navigation prints on top of every page, sites with a print stylesheet render something different from what you saw, backgrounds are stripped unless you tick "background graphics", and one row of a table ends up orphaned per sheet. It also needs a human. 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.

Getting it right means rendering in a real browser engine, waiting for the page to settle, then printing with proper page break rules. That is the pipeline SitePDF runs for every call: managed Chromium, a configurable wait for selector, then a print grade render to A4, Letter or Legal.

When a script of your own stops being cheap

For a developer, Puppeteer or Playwright converts a page with full fidelity, because it is Chrome doing the printing. Ten lines of Node will do it for a personal script. Running it in production is a different job: browser memory leaks, Docker images missing font packages (CJK text and emoji silently turn into boxes), render drift each time Chromium ships, and a queue to stop ten concurrent renders from eating a server.

That is the point where teams move the work to an API. You send a URL or raw HTML plus options, and get a finished PDF back. The provider owns the browsers, the fonts and the patching. If you want the one call version for live URLs, the URL to PDF API page has the parameters; if the input is markup your app already builds, convert HTML to PDF covers that path.

The part everyone forgets is what the page said

Most teams save a page as PDF because someone needs a record: a confirmation page after a payment, a published price, a policy as it stood on the day a user signed up. A PDF on a laptop is a weak record. Before you rely on one, check that it answers three questions.

When was it captured? A file modified date changes every time the file is copied. You want a timestamp written by the capture system.
What exactly was captured? The full source URL, and ideally the content as fetched, not just a picture of it.
Could it have been altered since? A PDF in a shared drive can be edited by anyone with access. A copy held in a system with a content hash taken at capture time is a different class of evidence.

SitePDF treats the record as part of the product. Any render can be archived with archive=true: a snapshot stored with its capture time and source URL, retrievable by API whenever someone asks. The document goes to your user, the timestamped archive goes to whoever asks in two years. For regulated teams, that archive page also covers what makes a snapshot defensible.

Save webpages as PDF on a schedule, not when you remember

The pages worth saving change without warning. Teams schedule renders to save pricing pages weekly, terms of service monthly, and campaign landing pages daily through a launch. Point a cron job at the API, or submit a batch of URLs from a sitemap, and each page comes back as its own PDF with its own archive entry.

A habit that holds up: capture before anyone needs the record, keep the timestamp and URL in the system rather than in a filename, restrict who can write to the store, and check now and then that old captures still open. If you also want an alert the moment a page moves, that is a separate tool category, and our comparison of website change monitoring tools covers what each charges and how long it keeps history.

Who buys a web page to PDF API

Three kinds of US teams pay for this rather than pressing Ctrl+P. SaaS products that let users export a dashboard, report or invoice as a PDF need the render inside the app, at whatever volume their users generate. Compliance and legal teams at financial services firms, insurers and marketplaces need dated copies of public pages they published or relied on. Operations teams that track competitor prices or partner terms need the same pages captured on a schedule, with the date attached.

All three outgrow the print dialog the first month the volume or the stakes go up. The demo above converts pasted HTML in your browser, so you can judge output quality before you pick a plan. Live URL capture runs through the API, because browsers will not fetch arbitrary sites cross origin. How it works shows the full flow.

The API call shape: URL in, rendered PDF plus a dated archive entry out. Run it from cron for scheduled captures.

curl https://api.sitepdf.com/v1/render \
  -H "Authorization: Bearer $SITEPDF_KEY" \
  -d url="https://example.com/pricing" \
  -d wait_for="#pricing-table" \
  -d format=Letter \
  -d archive=true

This is the documented API call shape. Full request and response walkthrough.

Questions about this job

What is the best way to save a webpage as a PDF?

For a single simple page, your browser print dialog is fine. For pages that matter or repeat, use a renderer built for it: real Chromium, proper page breaks, full page height, and a timestamped archived copy, so the file is a record and not just a file.

How is this different from pressing Ctrl+P in my browser?

Print dialogs use unpredictable print CSS, break layouts at arbitrary points and produce a file with no provenance. A rendering API waits for the page to finish loading, applies print rules consistently, runs unattended at any volume, and with SitePDF also stores a timestamped snapshot of the page.

Why does my saved PDF look different from the webpage?

Browsers apply print stylesheets and drop backgrounds by default, and pages that load content with JavaScript often print before they finish. A rendering API waits for the content, keeps the layout and prints the page as it actually displayed.

Can it handle pages that need JavaScript to display content?

Yes. Pages render in real Chromium with JavaScript enabled, and you can tell the render to wait for a specific selector so charts, tables and lazy content are on screen before the PDF is written.

Can I save a whole website as PDFs, not just one page?

Yes. Batch rendering is part of the API: submit a list of URLs, for example from the site sitemap, and each comes back as its own PDF with its own archive entry.

Can I convert a page behind a login?

Yes. Authenticated capture with custom headers and cookies renders pages behind a login, the same way a signed in browser would.

Does the saved PDF prove when the page was captured?

The PDF alone does not, because PDF metadata is editable. The archive entry SitePDF stores alongside the render does: capture time, source URL and the stored snapshot, retrievable later. That pairing is the point of the product.

Do you keep a copy of the pages I convert?

Only if you ask for it. By default a render is transient: we return the PDF and store nothing. With archive=true the snapshot is stored under your account, with retention you control and deletion on request.

Index

More PDF and archiving tools

Get started

Render and archive with one API call

A pixel perfect PDF and a dated copy of the page from the same request. Plans from $49 a month, half price billed yearly.