DEV Community: PetrDev

Website Compliance Monitoring Tools Compared (2026)

PetrDev — Mon, 26 Oct 2026 13:03:16 +0000

Originally published on the Site2PDF blog.

A compliance team does not need to know that a page changed. It needs to show, months later, what the page said on a given day — and that the copy it is showing has not been touched since.

The tools sold for it fall into four groups. This guide compares website compliance monitoring tools by group: what each records, what it proves, what it costs as of October 2026, and where it stops.

Quick answer

What you need	Group	Examples
A regulator-ready archive of every page, WORM storage, eDiscovery export	Regulated archiving platforms	Pagefreezer, Hanzo, MirrorWeb, Smarsh
An alert when a disclaimer, price or policy page changes	Change monitors	Visualping, ChangeTower, Fluxguard
A dated image of the same pages every day or week	Scheduled screenshot archives	Stillio
One capture you can hand to a lawyer, with a hash or signature	Evidence capture	Page Vault, Browsertrix, Site2PDF

What compliance monitoring has to prove

Three questions decide which tool fits, and the first is the easiest to answer.

Did the page change? A diff and an alert. Most tools below do some version of this.
What exactly did it say on that date? A stored copy of the whole page, dated, kept for the retention period your rules set.
Can anyone show the copy was not edited? A hash or a digital signature recorded at capture time, and a way for someone outside your company to check it.

Regulated industries spell these out. In US financial services, FINRA Rule 2210 requires firms to keep a copy of each retail communication — a website counts — with "the dates of first and (if applicable) last use", for the period set by SEC Rule 17a-4. That rule asks for "not less than three years" and for electronic records either "in a non-rewriteable, non-erasable format" or with "a complete time-stamped audit trail."

Outside finance the rules are looser, but the questions are the same: a price shown on a date, a terms page in force when a customer signed up, a health claim that was or was not on the page.

1. Regulated archiving platforms

These are built for questions 2 and 3 at the scale of a whole organisation. None of the four publishes a price — every one is quote or demo only (checked October 2026).

Pagefreezer says "every archived record is stored with a cryptographic hash value, timestamp, and digital signature," exports to "PDF, CSV, and eDiscovery-compatible formats," and targets FOIA, SEC and FINRA work. Its security page adds a timestamp from an external time-stamp authority.
Hanzo Chronicle stores captures as WARC in "immutable (WORM) storage" with "SHA-256 hash values," exports "auditor-ready PDF packages," and alerts teams "when disclaimers are changed or missing."
MirrorWeb archives in "ISO-standard WARC format, stored in a WORM environment," and names SEC 17a-4, FINRA 2210 and FCA COBS 4.
Smarsh Web Archive sets capture frequency "daily, weekly, or custom" per domain, keeps each capture "time-stamped and stored in its original form," and lets you "compare any two dates."

Where they stop: verification runs through the vendor. None of these pages publishes a public key or a stand-alone verifier, so a third party checks the record by trusting the vendor's portal, report or affidavit. Expect a sales call and an annual contract.

2. Change monitors

Change monitors answer question 1 well: they check a page on a schedule, show a visual or text diff, and send an alert.

Visualping — as of October 2026, free for 5 pages and 150 checks a month; Personal plans from $14/mo; Business features need a subscription of at least $140/mo. "Change history is kept for three months by default," one year on Business.
ChangeTower — as of October 2026, free for 3 pages checked daily with 30 days of history; Business is $78/mo for 200 pages, hourly, six months of history. Full-page archiving on every check and review workflows are Enterprise only, priced on request.
Fluxguard — as of October 2026, free for 3 sites; paid plans $110, $220 and $550 a month, with checks "as frequent as every 5 minutes" on the top plan.

Where they stop: the record is the diff and a limited history window. When you need the page as it looked on a date two years ago, the monitor may no longer hold it, and none of these three describes a hash or signature on the stored copy. The workflow for turning alerts into a kept record is in how to document website changes.

3. Scheduled screenshot archives

Stillio captures the same URLs daily, weekly or monthly and files the screenshots by date. As of October 2026 it starts at $29/mo for up to 5 pages and $79/mo for 25; every plan keeps screenshots for 36 months "provided there is an active subscription," with a 14-day trial.

Where it stops: a screenshot is an image. It shows the page, but text inside it is not searchable without OCR, and the file carries nothing that proves it was not edited. The trade-off between image and document formats is in PDF vs screenshot for archiving.

4. Evidence capture: one page you can defend

This group answers question 3 for a specific page, on demand or on a schedule.

Page Vault is built for litigation, and every capture includes a timestamp and a SHA-256 hash. Its On Demand service, where Page Vault captures for you, starts at $199 for websites as of October 2026; the browser software is quote only.
Browsertrix from Webrecorder crawls sites into WACZ files and says "crawl outputs are digitally signed to ensure a provable chain of custody." It is free for 7 days, then from $30/mo as of October 2026. WACZ opens in archive tools, not in a PDF reader.
Site2PDF captures a page or a whole site to PDF, PNG or JPG. Its legal capture option stamps the source URL and capture time on the PDF and issues a certificate with the file's SHA-256 hash and an RSA-2048 signature. The public key is published at a fixed address, so anyone can check a file with two stock commands — sha256sum and openssl dgst -verify — without an account and without trusting Site2PDF. Single-page legal capture is included on every plan, Free included.

Site2PDF also schedules captures (scheduled runs are plain archives; legal capture is a separate, on-demand step). A watch re-captures a page or a fixed list of pages daily, weekly or monthly, compares the page text with the last run, and can email you only when it changed. Free accounts get 3 watches; on Starter and above each capture can also go straight to Google Drive. Plans are on the pricing grid.

Where it stops: the fastest schedule is daily, so it does not replace a monitor that checks every few minutes. Files are kept for a period that depends on the plan, not in WORM storage, so the long-term copy is yours to store. The capture time is recorded by Site2PDF rather than an external time-stamp authority. And there is no WARC output or eDiscovery load file. The practices that make a capture hold up are in website archiving for legal purposes.

Side by side

Tool	Change alerts	Stored copy	Hash / signature	Checkable without the vendor	Published price
Pagefreezer	Not stated	PDF, CSV, eDiscovery	Hash, signature, TSA timestamp	Not published	No
Hanzo	Yes	WARC, PDF package	SHA-256	Not published	No
MirrorWeb	Not stated	WARC	Not stated on page	Not published	No
Smarsh	Date compare	Screenshot, source	Not stated on page	Not published	No
Visualping	Yes	Diff, 3–12 months	Not stated	—	Yes
ChangeTower	Yes	Diff; full page on Enterprise	Not stated	—	Yes
Fluxguard	Yes	3–100 versions per page	Not stated	—	Yes
Stillio	Not stated	Screenshot, 36 months	Not stated	—	Yes
Page Vault	Not stated	PDF, video	SHA-256	Not published	On Demand only
Browsertrix	Not stated	WACZ	Signed	Yes (open spec)	Yes
Site2PDF	Text change	PDF, PNG, JPG	SHA-256 + RSA	Yes (public key)	See pricing

Which one should you use?

A regulated firm with a recordkeeping rule (SEC, FINRA, FCA) → a regulated archiving platform. The WORM storage, retention controls and eDiscovery export are the product; book the demos.
Marketing or legal wants to know when a page changes → a change monitor. Pick by page count and check frequency.
You need a dated picture of the same pages for years → a scheduled screenshot archive like Stillio.
A dispute, a complaint or an audit about specific pages → an evidence capture. A signed PDF someone can verify with openssl, or a signed WACZ if your counterpart works with web-archive tools.
A small team that needs all three questions answered on a budget → combine them: scheduled captures with change emails for the running record, and a signed capture of any page that becomes evidence.

For a wider list that includes free public archives and self-hosted tools, see the best web archiving tools of 2026.

FAQ

Is a screenshot enough for a compliance record?

For internal tracking, often yes. For a regulator or a court, a screenshot alone is weak: it carries no proof that it was not edited. A capture with a hash recorded at the time, ideally signed, is stronger.

How long do I need to keep website records?

It depends on your rules. For US broker-dealers, SEC Rule 17a-4(b) sets "not less than three years, the first two years in an easily accessible place." Check the rules that apply to you, then check the tool's retention against them.

Can a third party verify a capture without trusting the tool that made it?

Only if the tool publishes how. Browsertrix signs WACZ files under an open specification, and Site2PDF publishes the public key that checks its signatures. The enterprise platforms above do not publish a key or verifier on their product pages.

The takeaway

Decide which of the three questions you must answer — what changed, what it said, and that the copy is untouched — before you compare prices. Regulated firms need a platform built for their recordkeeping rule. Everyone else can pair scheduled captures with a signed capture of the pages that matter: Site2PDF does both, and its signatures check against a key anyone can download.

Sources

How to Save Web Sources for Research (and Cite Them Later)

PetrDev — Mon, 19 Oct 2026 07:11:17 +0000

Originally published on the Site2PDF blog.

A link in a bibliography that returns 404 a year later is a citation that cannot be checked — and that outcome is routine, not rare. If a web source is going to end up in a paper, a report or a brief, saving it needs to produce three things: a copy you can quote from, a date the reader can trust, and a format that still opens on the day someone wants to check your work.

The right method depends on which of those you need most. Here are five ways researchers save sources, what each one is good for, and how to cite the result.

Quick answer

What you need	Use	What you end up with
A quick note of what the page said	Browser Print → Save as PDF	One PDF on disk, searchable
Dated proof of what the page showed	A full-page capture with the date on it	Searchable PDF, visible capture date
A citable public URL that will not rot	Internet Archive — Save Page Now	A permanent `web.archive.org/...` link
A library you can cite from inside Word	Zotero with the browser connector	Snapshot + metadata + citation key
A whole report, blog or docs site	A whole-site PDF archiver	One searchable PDF of every page

Why saving the link is not enough

A URL is not the source — it is a pointer, and pointers rot. The decay has a name (link rot): Harvard Law's Perma.cc project measured that half the URLs cited in US Supreme Court opinions no longer pointed to the right content a few years after publication.

Even when a URL still resolves, the page it serves may have been edited since. "Retrieved on March 4" means nothing unless you can also show what the page said on March 4. That is the gap every method below closes.

1. The quickest option: Save As PDF in your browser

For a one-off source you only need a copy of, the browser's own print dialogue is enough. It is free, available on every operating system, and the file opens anywhere.

Chrome / Edge: Ctrl+P (or Cmd+P), then set Destination to Save as PDF and press Save.
Firefox: Ctrl+P, then Save to PDF. See Mozilla's how to save a web page help page for the full options.
Safari: File → Export as PDF.

You get a text-selectable PDF of the page as it printed, which usually drops navigation and sidebars. What it does not catch: content behind an interaction (a closed accordion, a map), long pages that paginate oddly, and anything the browser has not finished rendering — see saving JavaScript websites as PDF.

Fine for background reading. Not enough when the exact wording and date are the evidence.

2. The dated archive: a searchable PDF of the page

For a source you are going to quote, you want three things in the file:

The page as it rendered, so what you saw is what the reader sees.
A text layer, so Ctrl+F finds a quote and copy-paste works.
A capture date inside the file, so the reader is not trusting your hard drive's modification time.

A full-page capture tool renders the page in a real browser, scrolls to the bottom so lazy-loaded images are there, strips the cookie banner, and writes one PDF with the text behind the pixels. In Site2PDF: paste the URL, choose PDF, press Generate. Every PDF ships with an invisible searchable text layer, so quotations stay copyable even though the page looks pixel-exact.

For high-stakes work — a legal brief, a thesis defence — the file can also carry a SHA-256 hash and an RSA signature of the capture, verifiable with stock openssl against a public key. That is the difference between "my PDF says March 4" and "the signature proves this PDF was not edited after March 4," covered in website archiving for legal purposes.

3. The permanent URL: Internet Archive's Save Page Now

If what you want is a link your reader can click — ideally one that will still work in 2035 — the free Save Page Now service at the Internet Archive is the standard tool. Paste the URL, press Save Page, and in a few seconds you get a dated permalink of the form web.archive.org/web/{timestamp}/{original URL}. The timestamp is baked into the URL itself — 20260319143022 reads as 19 March 2026 at 14:30:22 UTC.

The help page Save Pages in the Wayback Machine walks through the options. In short: use it for anything you want to cite as a public source, especially court filings and journal articles where editors require that cited URLs be archived.

What it does not do well: pages behind a paywall or a login (the archive does not have your session), heavily interactive apps, and PDFs served as blobs. For those, fall back to a local capture.

4. Keep everything together: Zotero

Zotero is a free, open-source reference manager that researchers use because it keeps the source, the metadata and the citation in one place. The browser connector saves a snapshot of the page into your library the moment you click it, pulls title, author, date and publisher from the page's metadata, and lets you drag the entry into Word or Google Docs as a formatted citation.

The quick start guide and the adding items page cover setup. The reason to use it even on a small paper: when you reformat from APA to MLA for a different submission every entry switches at once, and the saved snapshot is still there if the live URL has gone dark.

5. The whole site, not just one page

The methods above save one URL. For a government report split across fifteen pages, a product's docs site, or a whole blog, you need a tool that follows the links and saves every page.

A whole-site capture tool reads the site's sitemap (or follows its links), lists the pages so you can prune, and produces either one combined PDF or one file per page. Each page is rendered in a real browser, so dynamic content and lazy images are captured as they actually appear.

In Site2PDF this is Full Website mode: pick PDF, press Generate. The output is a single searchable PDF of every page — the format a researcher wants, because Ctrl+F works across the whole archive. The deeper walkthrough is in how to archive a website; the format trade-offs are in how to save a website as PDF.

A Free account covers small sites — up to 5 pages per archive, 2 archives per month — enough to try the format on a short report. Larger sites need a paid plan; see pricing.

How to cite a web source

Once you have saved the page, the citation itself is short. Both of the major style guides handle web sources explicitly.

APA 7th edition uses: Author or Organization. (Year, Month Day). Title of page. Site Name. URL. The APA guide's webpage and website references page lists the exact format, including when to add "Retrieved from" (only for pages designed to change over time, such as dictionary entries or dashboards). If you archived the page, cite the archived URL in place of the live one.

MLA 9th edition builds every citation from the same nine "core elements." The MLA Style Center's Works Cited: A Quick Guide and works cited pages walk through them: author, title of source, title of container (the site), publisher, publication date, location (URL). An access date is optional unless the source has no publication date.

Rule of thumb for both: if the page can change, cite the archived copy and mention the access date; if the page is a dated article, the archive is still useful as a backup, but cite the live URL first.

Which one should you use?

A quick read you may quote once → browser Save As PDF. Seconds, no account.
A quotation that is going into a published paper → a searchable, dated PDF on disk, archived with Save Page Now as the public link.
A reference you will reformat later or share with co-authors → Zotero. The snapshot and the citation live together.
A multi-page source — a whole report, a policy site, a documentation set → a whole-site PDF, one file to search across.
A disputed or legal source → a signed capture with a verifiable hash on top of all of the above.

Most dissertations end up using two of them: Zotero for day-to-day reading, and a dated PDF archive for anything that will show up in a direct quotation.

FAQ

Can I cite a web source whose URL has gone dead?

Yes, if you archived it. Cite the archived URL (for example, the web.archive.org/web/... permalink) in place of the live one, and keep the original URL in a note so a reader can see what has changed.

Do I need to add an access date to every web citation?

No. In both APA 7 and MLA 9, the access date is only required when the page carries no publication date or is designed to update. For a dated article, the publication date is enough.

Does my saved PDF need OCR to be searchable?

Only if the page was captured as an image (a plain screenshot). A PDF produced by a browser Save As, or by a tool that writes the page's text behind the pixels, is already searchable — no OCR step needed.

Is a screenshot good enough to cite?

For a journalist or a thesis supervisor, usually yes, as long as the capture date is visible in the file. For court or regulatory use, a plain screenshot is weaker evidence than a signed capture because the file has nothing in it that proves it was not edited after the fact.

What about paywalled articles?

Save them locally while you are logged in — the browser's Save As PDF captures the version you can see. Public archives like the Wayback Machine cannot see paywalled content, so for a paywalled source, your local dated PDF is the archive.

The takeaway

Save the page the day you read it, not the day you need to cite it. For a one-off reference the browser's Save As PDF is enough; for a quotation the reader must be able to verify, you want a dated, searchable PDF; for a public link that will outlive the original site, use the Internet Archive. When the source is a whole site rather than one page, site2pdf.online turns it into one searchable PDF in a few minutes.

Sources

How to Download a Website as a ZIP File

PetrDev — Sat, 17 Oct 2026 13:40:43 +0000

"Download the website as a ZIP" sounds like one task. It is three, and the right method depends on which one you mean:

The files of your own site — HTML, images, themes, maybe the database — so you can back it up or move it to another host.
A browsable copy of a site you don't control — everything a browser would load, saved to your disk so it opens offline.
A record of what every page looks like — one file per page, for a client, a dispute, or the version before a redesign.

Pick the wrong one and you get a ZIP that does not do what you needed: a folder of PHP files that will not open in a browser, or a "copy" of a modern site where every page is blank. Here is each method, what ends up inside the ZIP, and where it breaks.

Quick answer

What you need	Use	What's in the ZIP
Back up or move your own site	Hosting file manager, a backup plugin, or your host's deploy download	Source files (plus a database export, if the site has one)
An offline copy of any site	HTTrack, wget or SiteSucker, then compress the folder	The HTML, CSS, scripts and images the server sends
A record of how each page looks	A full-site capture tool that exports per-page files	One PDF (or PNG/JPG) per page, named after its URL

1. Your own site: download the source files

If you own the site, the cleanest copy comes from where it is hosted — not from the outside.

Hosting with cPanel or a similar file manager

Open File Manager and go to the site's folder — usually public_html.
Select everything, choose Compress, and pick ZIP Archive.
Download the ZIP that appears, then delete it from the server so it is not left publicly reachable.

This gets the files only. A WordPress site keeps its posts, pages and settings in a database, not in files — so also export the database (phpMyAdmin → Export) or the ZIP will restore an empty site.

WordPress

A backup plugin does both halves for you. UpdraftPlus, Duplicator and All-in-One WP Migration each package the files and the database into downloadable archives, and each can restore them on another host. This is the right tool when the goal is a move or a backup you can restore.

Static sites, Netlify and GitHub

Netlify: open a successful deploy in the Deploys list and download it — you get a ZIP of the built files Netlify actually serves (the output, not your framework source).
GitHub: if the site lives in a repository, Code → Download ZIP gives you the source.

Website builders: Webflow, Wix, Squarespace

Builders are the exception, because the site is generated on their servers:

Webflow can export HTML, CSS, JavaScript and assets as a ZIP from the Designer (Code export, or Shift+E) — on a paid Workspace plan only. CMS content, ecommerce and user accounts are not included.
Wix does not let you download or export a site's files; Wix staff confirm it is not possible.
Squarespace has no code export either.

For a Wix or Squarespace site, the closest thing to "the whole site in a ZIP" is method 3 below: a capture of every page as it renders.

2. Someone else's site: use a website copier

A website copier starts at a URL, follows the links, and saves every page and asset it finds into a folder, rewriting links so the copy can be browsed offline. Compress that folder and you have your ZIP (Windows: right-click → Send to → Compressed (zipped) folder; macOS: right-click → Compress).

HTTrack (Windows, Linux)

Free and open source. Create a project, enter the URL, choose Download web site(s), and let it run. For anything bigger than a few pages, set a depth limit and stay on the same domain, or it will happily start downloading the rest of the internet.

wget (any platform, command line)

wget --mirror \
  --convert-links \
  --adjust-extension \
  --page-requisites \
  --no-parent \
  https://example.com/

(On Windows, write it as one line without the backslashes.) --mirror follows links recursively, --page-requisites pulls the images and CSS each page needs, and --convert-links makes the copy work offline. Then: zip -r example.zip example.com.

SiteSucker (macOS)

A paid Mac App Store app that does the same job with a friendlier window. Paste the URL, press Download.

Where copiers break

Copiers save what the server sends. They do not run JavaScript. That used to be a footnote; now it is the main limitation:

Sites built with React, Vue or a builder often send a nearly empty page and build the content in the browser. The copy opens to a blank page or a loading spinner. (More on why in saving JavaScript websites as PDF.)
Anything behind a login is out of reach unless you pass the copier your session.
Search, forms and checkout stop working — there is no server behind the copy.
Lazy-loaded images that appear only on scroll are often missing.

Be considerate, too: limit the crawl speed, respect the site's terms, and keep a copy of someone else's site for your own reference — republishing it is a different matter.

3. A ZIP of what every page looks like

Sometimes you do not need the code at all. You need proof of what the site showed: the version a client signed off on, the page before a redesign, a competitor's offer on a given date, or a site that is about to go offline. For that, the useful ZIP holds one rendered file per page — and it is also the only option that works on Wix, Squarespace and JavaScript-heavy sites, because each page is rendered in a real browser before it is saved.

With Site2PDF:

Open the tool, choose Full Website, and paste the site's address.
It reads the site's sitemap — or follows its links when there is none — and lists the pages. Untick the ones you don't want and drag the rest into order.
Pick the format: PNG or JPG (images always come as a ZIP, on every plan), or PDF with Separate files · ZIP (a paid-plan option).
Press Generate Website Archive and download the ZIP when it is ready.

Inside, each page is its own file, numbered in your order and named after its URL — 001-home.png, 002-pricing.png, 003-blog-launch-notes.png. Every page is captured in real Chrome after scrolling to the bottom, so lazy-loaded images are there and cookie banners are removed. Choose PDF and each file also keeps an invisible text layer, so you can search it and copy text even though the page looks pixel-exact.

Prefer one file? Leave PDF on Single file and every page goes into one combined PDF — handy for handing a site over to a client. A free account covers small sites; larger sites need a paid plan or a one-off pack, and a ZIP of separate PDFs needs a paid plan — see pricing.

What this ZIP is not: editable source. You cannot upload it to a new host and get a working site back. It is a record — which is exactly what methods 1 and 2 do not give you.

Which one should you use?

Moving or backing up your own site → method 1. A capture is not a backup you can restore.
Reading a site offline, or studying how it is built → method 2, if the site is mostly plain HTML.
Showing what a site looked like, keeping a dated record, or saving a builder or JavaScript site → method 3.

Often the honest answer is two of them: a backup plugin for the files, and a PDF of every page for the record.

FAQ

Can I download an entire website as a ZIP for free?

Yes. Your host's file manager, HTTrack and wget are free, and so is a ZIP of page images of a small site in Site2PDF. What you get differs: files from the first ones, rendered pages from the last.

Does the ZIP include the database?

Only if you export it. Compressing the site's folder captures files; WordPress content lives in the database, so export it separately or use a backup plugin that bundles both.

Why is my downloaded copy blank or broken?

The site builds its pages with JavaScript and the copier does not run it. Use a tool that renders each page in a real browser before saving it.

Is it legal to download someone else's website?

Saving a copy for your own reference is generally fine; republishing it or reusing its content usually is not. Check the site's terms, and do not hammer the server with a fast crawl.

The takeaway

Decide what the ZIP is for before you make it. Files to restore come from your host. A browsable copy comes from a copier — if the site is plain HTML. A record of how each page actually looked comes from rendering the pages: site2pdf.online turns a whole site into a ZIP of PDFs in a few minutes.

Sources

How to Capture Many Web Pages at Once (Bulk URL List to PDF)

PetrDev — Sat, 17 Oct 2026 13:40:06 +0000

Capturing one web page is a solved problem — Chrome, Firefox and every browser extension do it. The job gets harder when the list is forty URLs: a competitor audit, every page in a client's redesign, a batch of policy pages to show a reviewer. Opening each one, scrolling to the bottom, and saving it by hand is where an afternoon goes.

Four methods actually work for a list, each for a different kind of person. Here is each one, what the output looks like, and where it falls over.

Quick answer

What you have	Use	Output	Needs code?
A handful of tabs already open	A browser extension (GoFullPage, FireShot)	One image or PDF per tab	No
Hundreds a day, same job every time	A screenshot API (ScreenshotOne, Urlbox, Browshot)	Per-URL files via HTTP	Yes
A one-off list, you already code	A short Puppeteer or Playwright script	Whatever you tell it to save	Yes
A list of URLs, no scripting	A bulk-list tool like Site2PDF	A ZIP of per-page files, or one combined PDF	No

1. A browser extension (one tab at a time)

Extensions like GoFullPage and FireShot capture whatever is in the active tab, scrolling it to the bottom and saving a PNG, JPG or PDF. Both have free tiers; GoFullPage is free with a paid tier for annotation tools, and FireShot's free tier watermarks captures.

For a list, they do not scale. You open each URL, press the button, confirm the save dialog, and go to the next tab. FireShot's Pro tier adds "batch capture of multiple URLs" and "batch capture of entire websites" from a list — that is the one feature that turns an extension into a bulk tool, and it is behind a paid licence (sold as a yearly subscription or a one-time lifetime fee).

Where they break:

JavaScript-heavy pages. An extension runs inside the browser you already opened, so what you see is what you get — but if the page is still loading when you press the button, half the content is missing.
Pages that need a login. An extension sees the session you are logged into; an API or a script needs cookies passed through.
Lists longer than your attention. Twenty by hand is bearable. Two hundred is a mistake waiting to happen.

Use an extension when the list is short, the pages are already open, and you want zero setup.

2. A screenshot or PDF API

Screenshot APIs — ScreenshotOne, Urlbox, ScreenshotAPI.net, Browshot, ApiFlash — render a URL on their servers in a real headless browser and return the file. Most of them expose a batch endpoint on paid tiers: Browshot has /api/v1/batch/create (thousands of URLs from a text file), ScreenshotAPI.net adds "bulk" to its Startup tier, Urlbox and ScreenshotOne charge per render on a monthly quota.

A tiny curl for one URL looks like this:

curl -o pricing.png \
  "https://api.screenshotone.com/take?url=https://example.com/pricing&access_key=KEY&full_page=true"

Looping that over a list is twenty lines of Bash or Python.

Where it breaks:

It is a developer product. The dashboard is for billing, not for "paste this list and get the files." You write code, parse errors, retry failures.
The output is per URL. You get pricing.png, about.png, blog-post-1.png — one file per request. Combining them into a single PDF or a tidy ZIP named after the right domain is on you.
Legal/integrity features are rare. Only Urlbox (Business tier) returns a SHA-256 hash and a timestamp with the file; none of the others. For legal archiving, that matters.

Use an API when you are capturing the same kind of page every day and the cost per render matters more than the setup time.

3. A short Puppeteer or Playwright script

If you already write a bit of JavaScript, twenty lines of Puppeteer or Playwright do what an API does, for free, on your own machine:

const puppeteer = require('puppeteer');
const urls = require('./urls.json');

(async () => {
  const browser = await puppeteer.launch();
  for (const url of urls) {
    const page = await browser.newPage();
    await page.goto(url, { waitUntil: 'networkidle0' });
    const name = url.replace(/^https?:\/\//, '').replace(/[^a-z0-9]+/gi, '-');
    await page.pdf({ path: `${name}.pdf`, format: 'A4', printBackground: true });
    await page.close();
  }
  await browser.close();
})();

That gets you a PDF per URL. Add fullPage: true for a PNG, or use page.screenshot() for an image. For a whole JavaScript site saved as PDF, the same loop works — you just feed it the sitemap.

Where it breaks:

You run it. When a URL throws a timeout at 3 a.m. nothing retries it.
Fixed headers, cookie banners and lazy images. The browser captures what is on screen; cleaning up all three takes more code than people expect.
No searchable text. page.screenshot() is a picture. page.pdf() keeps text, but only if the page uses system fonts — anything else needs an embedded font.

Use a script when the list is a one-off and you would rather own the capture than send URLs to a vendor.

4. A paste-a-list tool

The non-code answer is a tool that takes a list of URLs and gives back the archive. Site2PDF's Bulk URLs tab does this:

Open the tool and switch to Bulk URLs.
Paste the list — one URL per line, or separated by commas or spaces. The URLs can be from different websites; a competitor audit and an internal content review are the same shape of job here.
Press Continue. You see the pages, can untick ones you added by mistake, and can drag them into the order you want.
Pick a format: PDF, PNG or JPG. For PDF, choose Single file (every page in one combined document) or Separate files · ZIP (one PDF per URL, zipped). PNG and JPG always come back as a ZIP because several images cannot be merged into one file.
Press Generate and download the archive when it is ready.

What ends up inside, when the list spans multiple sites, is a ZIP whose files are named after the domain and the path: 001-example.com-pricing.pdf, 002-another-site.com-about-us.pdf. A single-domain list drops the domain and just numbers the pages, so a 40-page audit of one site reads cleanly: 001-home, 002-pricing, 003-features.

Where it breaks:

Bulk needs a free account. The signup is for your archive history and the plan allowance — a single-page capture does not require it.
The list is capped by your plan's per-archive page limit — the Free plan takes a short list; paid plans go up from there (see pricing). A one-off pack covers a single big list without a subscription.
A ZIP of separate PDFs is a paid-plan feature. PNG and JPG lists still come back as a ZIP on the free plan; what the free plan cannot do is choose to split a PDF list across files.

Use this when the list is big, mixed-domain, or you would rather paste URLs than write a script.

Which one should you use?

A dozen pages already open in tabs → an extension. GoFullPage free, FireShot free (watermarked) or FireShot Pro for batch.
A pipeline that runs every day → an API. Pick the one whose quota matches your volume; expect to write code around it.
A one-off list and you already code → Puppeteer or Playwright. Twenty lines, zero cost.
A one-off list and you don't code, or you want one combined PDF of the lot, searchable, with URL footers → a bulk-list tool. Especially if the list spans different domains or needs a dated record for a client handoff.

Two of these often live in the same workflow. A SEO team might script monthly competitor captures with Puppeteer and use the paste-a-list tool for one-off audits. An agency uses the extension for live review and the bulk tool to bundle a project when it ships.

FAQ

Can I bulk-screenshot websites for free?

Yes, up to a point. A browser extension is free for one tab at a time. A short Puppeteer script is free, on your machine. Several screenshot APIs include a free tier of around 100 renders a month. A bulk paste-a-list tool like Site2PDF has a free tier that fits short lists; longer ones need a paid plan or a one-off pack.

How do I keep the pages in the order I pasted?

The order you paste is the order the archive uses. Site2PDF numbers each file by position (001-, 002-, 003-), and the review step lets you drag rows if you need to reorder them. An API or a script keeps the order of the input list — unless you parallelise, in which case you have to sort by index yourself.

Can I bulk-capture a site that needs a login?

Yes with a script (pass the session cookie to Puppeteer), yes with an extension (it uses the browser session you already have), partially with APIs (some accept cookies as a parameter; many do not). Bulk tools vary — Site2PDF's Bulk URLs is for public pages.

What about full-page vs just the visible area?

For a list, you almost always want full-page: scrolled to the bottom, lazy images loaded, cookie banner removed. Every method above supports it; see how full-page screenshots actually work for the mechanics and the usual gotchas.

What is the difference between a bulk screenshot and a full-site archive?

A bulk screenshot takes a list you supplied. A full-site archive discovers the pages — from the sitemap or by following links — and captures them. Bulk is right when you already know which URLs matter; full-site is right when you want "everything the public can see."

The takeaway

For a short, same-domain list, open each page and use an extension. For a daily pipeline, pay for an API. For a one-off list — mixed domains, forty URLs, something you want as one searchable PDF or a per-page ZIP — paste it into site2pdf.online, pick the format, and let it run.

Sources

Never run Puppeteer inside a web request: scheduled captures with WP-Cron + a background worker

PetrDev — Tue, 01 Sep 2026 10:42:51 +0000

We let people put a URL on a schedule: re-capture this page daily, weekly, or monthly, and email me only when it actually changes. Simple feature, one sharp edge — and we found it in production.

The naive version runs the capture where the request is: user hits "check now", PHP shells out to headless Chrome, waits for the PDF, responds. It works on your machine. Then a handful of schedules come due in the same window, each capture holds a PHP worker for the 10–40 seconds Chrome takes, and the FPM pool is exhausted. On 2026-08-01 that's exactly what happened to us: synchronous captures inside web requests starved the pool and the whole site stopped answering.

The rule that came out of it: no PHP process — web request or cron — ever waits on headless Chrome. Here's the architecture that enforces it.

The shape

Two phases, deliberately split across cron ticks:

Dispatch — a cron tick finds due schedules and hands each one to a background worker (the same one the interactive tool already uses). It records a job_id and returns immediately.
Collect — a later tick picks up finished jobs, diffs the content against the previous run, keeps or discards the archive, and emails the owner.

Nothing blocks. The capture runs detached; cron just bookkeeps.

The cron tick

WordPress cron isn't a real cron — it fires on traffic — but for daily-or-slower schedules that's plenty. We register a 15-minute tick (the interval is about collect latency, not schedule precision: a dispatched job needs a later tick to be noticed, so 15 min bounds how long "Run now" takes to report).

function webtools_watches_run_due() {
    if ( get_transient( 'webtools_watches_lock' ) ) return; // a previous tick still running
    set_transient( 'webtools_watches_lock', 1, 10 * MINUTE_IN_SECONDS );

    // Phase 1: collect anything that finished since last tick.
    webtools_watches_collect_jobs();

    // Phase 2: dispatch what's due — bounded, so a burst can't stall anything.
    $now = time();
    foreach ( webtools_watches_all() as $id => $w ) {
        if ( ! empty( $w['job_id'] ) ) continue;             // already in flight
        if ( ( $w['status'] ?? '' ) === 'active' && (int) $w['next_run'] <= $now ) {
            $due[] = $id;
        }
    }
    // oldest-due first, capped at WEBTOOLS_WATCHES_PER_TICK; the rest wait for the next tick
    // ...
    delete_transient( 'webtools_watches_lock' );
}

Three things that matter more than they look:

A transient lock so overlapping ticks don't double-dispatch.
A per-tick cap (WEBTOOLS_WATCHES_PER_TICK) plus a ceiling on simultaneous Chrome jobs (WEBTOOLS_WATCH_JOBS_MAX) — each capture is its own headless browser, so unbounded concurrency is just the original outage with extra steps.
job_id as a mutex. A schedule with a job in flight is skipped, so it can never dispatch twice.

Dispatch: advance the schedule now, not later

The subtle bug we designed out: if you advance next_run when the job finishes, a job that dies never advances, and the schedule fires it again every tick forever. So next_run is bumped at dispatch, and the in-flight job_id is what prevents a re-dispatch. A dead job costs one missed run, not an infinite loop.

function webtools_watch_dispatch( $id ) {
    $watch = webtools_watch_get( $id );
    if ( ! $watch || ! empty( $watch['job_id'] ) ) return;

    $job_id = webtools_launch_site_job( [ /* url, format, device, selectors… */
        'watch_id' => $id,
    ] );

    $patch = [ 'next_run' => webtools_watch_next_run( $watch['frequency'], time() ) ];
    if ( $job_id ) { $patch['job_id'] = $job_id; $patch['job_started'] = time(); }
    webtools_watch_update( $id, $patch );
}

A single-page schedule is just a one-URL job, so the same path serves "watch this page" and "watch this whole site" — the site variant captures a fixed page list chosen up front, so later runs stay comparable and the cost can't quietly balloon.

Collect: diff the text, not the pixels

When a job reports done, we compare it to the previous run. The comparison is on a text hash per page, not the image — the worker records a textHash while it has the DOM open, and we diff those:

$prev  = (array) ( $watch['page_hashes'] ?? [] );
$fresh = [];
foreach ( $job['pages'] as $p ) {
    if ( $p['status'] === 'done' && ! empty( $p['textHash'] ) ) {
        $fresh[ $p['url'] ] = $p['textHash'];
    }
}

$first   = empty( $prev );
$changed_pages = [];
foreach ( $fresh as $url => $hash ) {
    if ( isset( $prev[ $url ] ) && $prev[ $url ] !== $hash ) $changed_pages[] = $url;
}
$changed = $first ? true : ! empty( $changed_pages );

Text hashing sidesteps the classic monitoring false positive: a pixel diff screams every time an ad rotates or a carousel advances. Hashing the extracted text ignores all of that and fires on content that actually changed. The first run is a silent baseline — there's nothing to compare to yet — so you don't get an email announcing that a page you just added "changed."

Then it's just policy: notify every run, only on change, or off (still archive, never email). In change-only mode an unchanged run's archive is deleted rather than kept as a duplicate.

What this bought us

The site can't be taken down by its own scheduled work — captures are detached, cron only bookkeeps.
A dead or stuck job self-heals: next_run already moved, and a timeout closes out the job_id so the schedule resumes.
Change detection is cheap and quiet, because it compares meaning (text) not appearance (pixels).

The general lesson travels beyond WordPress: anything that can take tens of seconds — headless browsers, video transcode, big PDF assembly — does not belong in the request that a user (or cron) is waiting on. Dispatch it, record a handle, collect it later.

This runs on every scheduled capture at Site2PDF. If you want the non-engineering version — how to actually use scheduled snapshots to track a page over time — we wrote how to document website changes.

Making a screenshot PDF searchable — no OCR, because we rendered the page

PetrDev — Thu, 20 Aug 2026 12:44:24 +0000

We archive whole web pages as PDFs. Under the hood each page is a full-height screenshot dropped onto a PDF page — which looks perfect and is completely useless the moment you want to use the text. Ctrl+F finds nothing. You can't copy a sentence. A screen reader opens the document and sees… an empty page with one big image.

The fix is the same trick a "searchable scan" uses: draw the real text invisibly, on top of the image, at the exact coordinates where each word appears. The difference is that a scanner needs OCR to guess the text — we rendered the page ourselves, so we already have the ground truth. No OCR, no guessing.

Here's how we built it with pdf-lib and @pdf-lib/fontkit, and the one part that turned out to be genuinely hard.

The shape of it

While the page is still open in the headless browser, ask the DOM where every word is.
Assemble the PDF: embed the screenshot as the page background.
For each word, drawText it at its coordinates with opacity: 0.

Steps 1 and 3 are easy. The trap is in which words you're allowed to draw.

Step 1 — ask the browser where the words are

Running inside the page (Puppeteer's page.evaluate), we walk every text node and measure each word with a Range:

const walker = document.createTreeWalker(document.body, NodeFilter.SHOW_TEXT);
// ...for each word in each text node:
const range = document.createRange();
range.setStart(node, start);
range.setEnd(node, end);
const rects = range.getClientRects();
if (!rects.length) continue;           // display:none or empty line box
const b = rects[0];                    // first rect = where the word starts
out.push({
  t: word,
  x: b.left + window.scrollX,          // document coordinates, not viewport
  y: b.top  + window.scrollY,
  w: b.width, h: b.height,
  fs: parseFloat(getComputedStyle(el).fontSize) || 12,
});

getClientRects() gives viewport coordinates, so we add scrollX/scrollY to get document coordinates — the ones that line up with a full-page screenshot. A word wrapped across two lines returns several rects; the first is where a search should land, so that's the one we keep.

Step 2 — the hidden-text trap (the hard part)

The naive version above shipped a bug immediately. On a real page, search started highlighting words that weren't in the picture — items inside a collapsed dropdown menu, off-canvas nav, text-indent: -9999px SR-only text. The image showed them collapsed; the text layer had them anyway.

The tempting assumption is "hidden text has no client rects." It's false. Only display: none produces no rects. Every other way of hiding something still reports perfectly good coordinates:

visibility: hidden
opacity: 0
max-height: 0 + overflow: hidden (the collapsed accordion / submenu)
parked offscreen with text-indent: -9999px or a negative position

So each word has to be checked against its whole ancestor chain, not just its own box. We memoise one walk up the tree per element (a deep DOM would otherwise re-read computed styles thousands of times):

function chainInfo(el) {
  if (cache.has(el)) return cache.get(el);
  const above = el.parentElement ? chainInfo(el.parentElement)
                                 : { visible: true, opacity: 1, clips: [] };
  let info;
  if (!above.visible) {
    info = { visible: false, opacity: 0, clips: above.clips };
  } else {
    const cs      = getComputedStyle(el);
    const opacity = above.opacity * (parseFloat(cs.opacity) || 0);   // multiplied down the chain
    const visible = cs.visibility === 'visible' && opacity > 0.05;
    const clips   = /\b(hidden|clip)\b/.test(cs.overflow)
      ? above.clips.concat([el.getBoundingClientRect()])
      : above.clips;
    info = { visible, opacity, clips };
  }
  cache.set(el, info);
  return info;
}

A word survives only if its chain is visible, its multiplied opacity is above a floor, it intersects every clipping ancestor (a zero-height collapsed container clips its contents to nothing), and it isn't parked entirely outside the document box. Clipping is judged on zero intersection, not partial — a word half-cut by a container is still half in the picture, and dropping it would lose real text.

That single ancestor-walk is the difference between "searchable PDF" and "PDF that lies about what's in it."

Step 3 — flip the Y axis

The DOM measures from the top-left; PDF space is bottom-left. So when we draw, Y inverts, plus a small nudge so the selection highlight sits on the glyphs rather than below them:

const y = imageH - b.y - b.h + b.h * 0.2;

Step 4 — the font problem

pdf-lib's built-in fonts are WinAnsi. They can't encode Cyrillic, Greek or CJK — and they even choke on curly typographic quotes, of which there are four on our own English blog. Draw an unencodable glyph and the call throws.

So we embed a real TrueType font, subset to only the glyphs actually used, via fontkit:

const fontkit = require('@pdf-lib/fontkit');
doc.registerFontkit(fontkit);
const font = await doc.embedFont(fs.readFileSync(fontPath), { subset: true });

subset: true is what keeps the cost near zero — only the handful of glyphs on the page get embedded, not the whole 300 KB face. We probe a small candidate list and take the first that exists on the box (DejaVu Sans on our Linux servers covers Latin + Cyrillic + Greek; Arial/Segoe locally). If none is found, we ship the image without a text layer rather than failing the capture — losing search is not losing the archive.

Step 5 — draw it invisibly, and don't let one glyph kill the archive

for (const b of boxes) {
  const y = imageH - b.y - b.h + b.h * 0.2;
  try {
    pdfPage.drawText(b.t, { x: b.x, y, size: b.fs, font, opacity: 0 });
    drawn++;
  } catch (e) {
    skipped++;   // a glyph even this font can't encode — skip the word, keep the PDF
  }
}

opacity: 0 is the whole point: the image is what you see, the text is what you search. And the per-word try/catch matters — a single exotic glyph should cost you one unsearchable word, not the entire multi-page document.

Did it actually work?

Measured on a Cyrillic page before/after:

626 of 626 visible words got coordinates and a text entry
file grew 7086 KB → 7147 KB — +0.9%
/ToUnicode is present in the output, so the text is genuinely searchable and copyable, not just present

That +0.9% buys you Ctrl+F, copy-paste, and a document a screen reader can actually read — on what is still, pixel for pixel, an exact image of the page.

We do this on every capture at Site2PDF — it archives a page (or a whole site) as a PDF/PNG/JPG, and the PDF comes out searchable by default. If you want the end-user version of this rather than the engineering one, we wrote up how to save a website as PDF.

Converting a JavaScript-Rendered Web Page to PDF

PetrDev — Sat, 01 Aug 2026 09:58:41 +0000

If you've ever tried to turn a modern web page into a PDF programmatically, you've probably hit the wall: the file comes out blank, half-empty, or frozen on a loading spinner. The page looks perfect in the browser, so what gives?

The answer is timing. Most PDF approaches grab the HTML before the JavaScript has rendered the content. On a server-rendered page that's fine — the markup is already there. On a React/Vue/Angular app, the server sends an near-empty shell and the browser builds the DOM afterward. Capture too early and you save the shell.

Here's how to do it properly.

Why the naive approaches fail

wkhtmltopdf is the classic Google answer. It's fast and it's been around forever, but it uses an ancient WebKit build with effectively no modern JavaScript support. For a static page it's fine. For anything client-rendered, it captures the empty state.

Browser window.print() / Ctrl+P works because it is a real browser — but it's manual, single-page, and impossible to automate cleanly at scale.

Hitting the raw HTML with an HTTP client (axios/fetch then pipe to a PDF lib) has the same fatal flaw as wkhtmltopdf: no JS execution, no rendered content.

What you actually need is a real browser engine that runs the page's JavaScript, waits for it to settle, and then prints. That's Puppeteer.

The Puppeteer approach

Puppeteer drives a headless Chromium. It executes the page exactly like a normal Chrome tab, so whatever renders on screen is what you capture.

const puppeteer = require('puppeteer');

async function pageToPdf(url, outPath) {
  const browser = await puppeteer.launch({
    args: ['--no-sandbox', '--disable-setuid-sandbox'], // needed in most containers
  });
  const page = await browser.newPage();

  await page.goto(url, { waitUntil: 'networkidle0', timeout: 60000 });

  await page.pdf({
    path: outPath,
    format: 'A4',
    printBackground: true, // otherwise CSS backgrounds/colors are dropped
    margin: { top: '20px', bottom: '20px', left: '16px', right: '16px' },
  });

  await browser.close();
}

pageToPdf('https://example.com', 'out.pdf');

Two options here matter more than they look:

waitUntil: 'networkidle0' tells Puppeteer to consider navigation finished only when there have been no network connections for 500ms. For most SPAs that's the signal the data has loaded and the DOM is built. (networkidle2 allows up to 2 connections — useful for pages with long-polling or analytics beacons that never fully go quiet.)
printBackground: true — forget this and every background color, gradient, and image disappears, because Chrome's print path strips them by default.

The gotchas that still bite you

Getting a non-blank PDF is step one. Getting a correct one is where the edges show up.

Lazy-loaded content

Images and sections that load on scroll won't be in the PDF, because Puppeteer never scrolled. Force them in by auto-scrolling before you print:

await page.evaluate(async () => {
  await new Promise((resolve) => {
    let y = 0;
    const step = 300;
    const timer = setInterval(() => {
      window.scrollBy(0, step);
      y += step;
      if (y >= document.body.scrollHeight) {
        clearInterval(timer);
        window.scrollTo(0, 0);
        resolve();
      }
    }, 100);
  });
});

Web fonts not loaded yet

Text renders in a fallback font because the web font hadn't finished loading at print time. Wait for it explicitly:

await page.evaluateHandle('document.fonts.ready');

Print CSS overriding your layout

If the site ships a @media print stylesheet, Chrome applies it. Sometimes that's what you want; sometimes it nukes the layout. Force screen rendering with:

await page.emulateMediaType('screen');

Fixed headers repeating or covering content

Sticky/fixed elements can duplicate on every PDF page or overlap the body. The reliable fix is to neutralize them before printing — set their position to static (or hide them) via page.addStyleTag().

When self-hosting Puppeteer isn't worth it

Puppeteer is the right tool when you need PDFs inside a pipeline you control. But it comes with a real operational tail: a headless Chromium is heavy (200MB+), it needs the right system libraries in your container, it leaks memory if you don't manage browser instances carefully, and it falls over under concurrency unless you pool pages and cap parallelism. For a side feature — "let users export this page" — that's a lot of infrastructure to babysit.

If you just need the output and not the plumbing, a hosted service does the same headless-render-then-capture under the hood without the ops burden. I run site2pdf.online for exactly this — it renders each page in real Chrome (so JS content comes through), and it can also follow a site's internal links to capture multiple pages in one pass, exporting to PDF, PNG, or ZIP. Handy when the alternative is standing up and maintaining your own Chromium fleet.

Rule of thumb: if PDF generation is core to your product, self-host Puppeteer and own it. If it's a convenience feature at the edge, offload it.

Wrapping up

The blank-PDF problem is almost always a timing problem: capture happens before JavaScript renders. Use a real browser engine, wait for the network (and fonts) to settle, scroll to trigger lazy content, and enable printBackground. Do that and dynamic pages convert cleanly.

The full, copy-pasteable version of this — plus the fixed-header and multi-page handling — is worth keeping in a snippet somewhere. You'll reach for it more often than you'd expect.

I shipped a website-to-PDF SaaS on WordPress — here's the stack

PetrDev — Tue, 05 May 2026 09:09:28 +0000

Last month I launched Site2PDF — converts any website to PDF, PNG, JPG or ZIP. Here's the entire tech stack, because the choices might be useful if you're building something similar.

What it does

Paste a URL → get a PDF of the whole page (or the whole site). Free plan gives 5 archives/month, all formats, cookie banner removal. Paid starts at $9/mo for 15 archives and 200 pages per site.

The stack

Frontend: a custom WordPress theme. Yes, WordPress. Hear me out.

Native user accounts, sessions, roles
Native admin panel for analytics and user management
Customizer for site branding
Gutenberg-free, just PHP templates + SCSS + vanilla JS

Rendering: Node.js + Puppeteer running on the same VPS, called from PHP via proc_open. A bash-like pattern:

$command = sprintf(
    '%s %s %s %s --options-file %s',
    escapeshellarg($node_path),
    escapeshellarg($script),
    escapeshellarg($url),
    escapeshellarg($output),
    escapeshellarg($options_json)
);
exec($command . ' 2>&1', $output, $code);

PHP passes options (cookie hide, selectors to expand, etc.) as a temp JSON file the Node script reads.

PDF assembly: pdf-lib for multi-page PDFs (each page becomes its own PDF page). DOMPDF for single-page fallback.

Image processing: sharp for PNG→JPG conversion. archiver for ZIP.

Billing: Paddle Billing (started with Stripe, had to migrate — Stripe doesn't support my country). Paddle handles tax, EU VAT, Canadian GST etc. — a huge win for a solo founder.

Auth: Google OAuth 2.0 without any plugin. A REST API endpoint redirects to Google, callback sets a one-time login token, cookie is set on the next regular page load. Why? Because iOS Safari blocks cookies set during REST API redirects (ITP).

Infra: Contabo VPS ($5/mo). Nginx, PHP-FPM, MariaDB. Chrome installed as google-chrome-stable, Puppeteer launches it with executablePath override.

Why WordPress (not Next.js or Rails)

The honest answer: I've shipped WP for 10 years. Familiar tools win. The theme is under 4000 lines of PHP, ~2000 lines of SCSS. I didn't need a full framework for ~5 pages and a wizard UI.

WordPress also gives me:

Zero-effort admin for users, plans, payment history
Free page hierarchy (/pdf-tools/full-page-screenshot/)
Built-in Yoast SEO and Site Icon features

The hot take: WordPress is a perfectly fine backend for a simple SaaS if you disable the bloat and write real code. Most of the "WordPress is slow" complaints come from bloated themes and 40 plugins.

Things that bit me

Puppeteer fullPage + fixed headers — writeup in my other post
Cookie banners blocking the screenshot — had to intercept requests to policy.cookiereports.com before page load
iOS Safari OAuth — first attempt set the auth cookie inside the callback redirect. Safari's ITP killed it. Had to use one-time tokens + set cookie on a regular page navigation.
iCloud Private Relay breaking CSRF state — used IP hash as the state key, which broke when Apple rotates IPs between redirects. Switched to state-as-key.
Paddle sandbox vs production — separate accounts, separate keys, separate price IDs. Wrote a helper that picks the right IDs based on WEBTOOLS_PADDLE_ENV constant.

The architecture in one diagram

Browser (vanilla JS)
  → AJAX → PHP (screenshot-tools.php)
          → proc_open → Node worker (Puppeteer)
          → writes PNG to /uploads/screenshot-temp/
          → PHP assembles PDF/ZIP if needed
          → returns base64 or job ID
  ← polls status / downloads blob

Full-site mode uses a different flow (background worker + status polling). Single-page mode is one synchronous AJAX call.

What's next

Real API (the pricing page still says "API — Soon")
Subscription cancel button in-app (currently "email us")
Blog with the 2-3 dev.to posts ported over for SEO

Try it

site2pdf.online. Free plan doesn't need signup. If you try it and something breaks, the Contact form works.

Happy to answer any questions about the stack in the comments.

Cleaning up web pages for screenshots — a practical Puppeteer guide

PetrDev — Wed, 29 Apr 2026 10:42:41 +0000

If you've ever taken a screenshot of a real-world webpage with Puppeteer, you've seen the ugly truth: cookie banners, sticky headers frozen at weird positions, collapsed FAQ accordions, and "Subscribe!" popups.

Here are four small Puppeteer helpers I use to get clean, presentable screenshots. Each is one function, drop-in ready.

1. Kill cookie banners

async function hideCookieBanners(page, customSelectors = []) {
    await page.evaluate((selectors) => {
        // Known cookie-banner elements
        ['CookieReportsPanel', 'CookieReportsOverlay', 'CookieReportsBannerAZ']
            .forEach(id => document.getElementById(id)?.remove());

        document.querySelectorAll('[class*="wscr"],[id*="CookieReport"]')
            .forEach(el => el.remove());

        // Reset body scroll locks the banner often sets
        document.body.style.overflow = '';
        document.documentElement.style.overflow = '';

        // User-defined selectors (if they know their site)
        selectors.forEach(sel => {
            try {
                document.querySelectorAll(sel).forEach(el => {
                    el.style.setProperty('display', 'none', 'important');
                });
            } catch {}
        });
    }, customSelectors);
}

2. Hide arbitrary elements

async function hideElements(page, selectors) {
    if (!selectors.length) return;
    await page.evaluate(sels => {
        sels.forEach(sel => {
            try {
                document.querySelectorAll(sel).forEach(el => {
                    el.style.setProperty('display', 'none', 'important');
                });
            } catch {}
        });
    }, selectors);
}

Example: hide chat widgets, "cookies" bars, floating "Get started" buttons:

await hideElements(page, [
    '#intercom-container',
    '.crisp-client',
    '[class*="newsletter-popup"]'
]);

3. Unfix sticky headers

Sticky headers repeat on every "screen" of a fullPage screenshot — ugly. Convert them to position: relative:

async function unfixSticky(page, selectors) {
    await page.evaluate(sels => {
        sels.forEach(sel => {
            try {
                document.querySelectorAll(sel).forEach(el => {
                    el.style.setProperty('position', 'relative', 'important');
                    ['top', 'bottom', 'left', 'right', 'z-index']
                        .forEach(p => el.style.setProperty(p, 'auto', 'important'));
                    el.style.setProperty('width', '100%', 'important');
                });
            } catch {}
        });
    }, selectors);
}

4. Expand FAQs / accordions

Most FAQs use classes like _active or attributes like open. Give the function a CSS selector + action + value:

async function expandAccordions(page, pairs) {
    if (!pairs.length) return;
    await page.evaluate(rules => {
        rules.forEach(({ selector, action, value }) => {
            try {
                document.querySelectorAll(selector).forEach(el => {
                    if (action === 'class') {
                        el.classList.add(value || '_active');
                        // Also unhide next sibling (common FAQ pattern)
                        const next = el.nextElementSibling;
                        if (next) {
                            next.style.display = 'block';
                            next.style.maxHeight = 'none';
                            next.removeAttribute('hidden');
                        }
                    } else if (action === 'attribute') {
                        const [name, val = ''] = value.split('=');
                        el.setAttribute(name, val);
                    } else if (action === 'style') {
                        value.split(';').forEach(rule => {
                            const [p, v] = rule.split(':');
                            if (p && v) {
                                el.style.setProperty(p.trim(), v.trim(), 'important');
                            }
                        });
                    }
                });
            } catch {}
        });
    }, pairs);

    // Wait for CSS transitions
    await new Promise(r => setTimeout(r, 400));
}

Example usage:

await expandAccordions(page, [
    { selector: '.faq__question', action: 'class', value: '_active' },
    { selector: 'details', action: 'attribute', value: 'open=true' },
    { selector: '.accordion-body', action: 'style', value: 'display: block' }
]);

Putting it together

await page.goto(url, { waitUntil: 'domcontentloaded' });
await hideCookieBanners(page);
await hideElements(page, ['.chat-widget']);
await unfixSticky(page, ['.sticky-nav']);
await expandAccordions(page, [{ selector: '.faq__q', action: 'class', value: '_open' }]);
await page.screenshot({ path: 'clean.png', fullPage: true });

Where I use this

All four helpers ship in production on Site2PDF — a website-to-PDF tool I'm building. Users paste a URL, tick what to hide/expand, and get a clean archive.

If you're doing any kind of web scraping or automated screenshots, grab these — they'll save you a weekend of CSS archaeology.

Why your fixed header disappears in Puppeteer fullPage screenshots (and how to fix it)

PetrDev — Thu, 23 Apr 2026 15:54:52 +0000

I spent two evenings debugging this. Sharing so you don't have to.

The problem

When you call page.screenshot({ fullPage: true }) on a site with a position: fixed header, one of three things usually happens:

The header renders in the middle of the page (not at the top)
The header area is blank at the top of the PDF/PNG
Only the first page shows the header — subsequent "pages" don't

You open the site in a real browser: looks perfect. You open it in Puppeteer's viewport mode: also fine. Only fullPage: true breaks it.

Why this happens

Puppeteer's fullPage: true uses Chrome DevTools Protocol's captureBeyondViewport. Under the hood, Chrome rasterizes the whole document beyond the viewport — but position: fixed elements are painted relative to the current viewport, not the document. So if your script scrolled to the bottom of the page before taking the screenshot, the fixed header is captured at the bottom.

There's also a second issue: many sites have scroll-behavior: smooth on html. When you call window.scrollTo(0, 0), the scroll is animated and doesn't complete instantly. If Puppeteer captures before the animation finishes, header ends up in a weird intermediate position.

The fix

Three things need to happen before the screenshot:

Kill smooth scrolling so scrollTo is instant
Reset any hide-on-scroll transforms that JS scroll handlers may have applied
Actually scroll to (0, 0) and wait a tick for paint

Here's the code I use in production:

async function prepareForScreenshot(page) {
    await page.evaluate(() => {
        // Disable smooth scrolling — make scrollTo instant
        const style = document.createElement('style');
        style.textContent = 'html { scroll-behavior: auto !important; }';
        document.head.appendChild(style);

        // Reset hide-on-scroll state on common header selectors
        const headers = document.querySelectorAll(
            'header, .header, [class*="header" i], nav[class*="header" i]'
        );
        headers.forEach(el => {
            const cs = window.getComputedStyle(el);
            if (cs.position === 'fixed' || cs.position === 'sticky') {
                el.style.setProperty('transform', 'none', 'important');
                el.style.setProperty('opacity', '1', 'important');
                el.style.setProperty('visibility', 'visible', 'important');
                if (cs.display === 'none') {
                    el.style.setProperty('display', 'flex', 'important');
                }
                // Remove common "hidden on scroll down" classes
                ['hidden', 'is-hidden', 'scroll-up', 'scroll-down', 'header--hidden']
                    .forEach(c => el.classList.remove(c));
            }
        });

        // Scroll to top — now instant
        window.scrollTo(0, 0);
    });

    // Give the browser one paint frame to settle
    await new Promise(r => setTimeout(r, 300));
}

Call it right before page.screenshot:

await prepareForScreenshot(page);
await page.screenshot({ path: 'out.png', fullPage: true });

When the simple fix isn't enough

If the site has a transparent header overlaid on a hero (common modern pattern), the above works great — the header just renders on top of the hero like in a browser.

If the site has a hide-on-scroll JS library that listens to scroll events after your reset, you may need to dispatch a synthetic scroll event to let it re-evaluate:

window.scrollTo(0, 0);
window.dispatchEvent(new Event('scroll'));

What I'm building

I'm working on Site2PDF — a tool that converts any website to PDF, PNG, JPG or ZIP. This exact fix is running in production there. If you want to try it, the free plan is 5 archives/month with all formats and advanced options (cookie banner removal, sticky header unfix, accordion expansion).

Feedback welcome!