TL;DR

There is no button that turns an entire website into PDF in one click — not in this extension, not in any browser-based tool that runs locally in your browser. What you actually do is: get a list of every URL on the site (sitemap.xml, site navigation, or a manual list), then visit and convert each page individually with Convert: Web to PDF, building up a folder of clean, individually-named PDFs. It's manual, it's page-by-page, and for anything under a few dozen pages it's faster than it sounds. This guide is the actual step-by-step — not a "which archiving method should I use" comparison (we already wrote that one, here). This one assumes you've already decided PDF is the format and just need the workflow for doing it across a whole site.

Why there's no "convert whole site" button

Worth saying up front, because some tools out there imply otherwise: a browser extension can only act on the tab that's open in front of it. It can convert the page you're looking at right now to PDF. It cannot reach out across the internet, discover every URL on a domain, open each one in the background, and convert them all while you get coffee.

Tools that claim to do exactly that — "paste a domain, get a PDF of the whole site" — are running a crawler on a server somewhere. That server has to fetch every page, which means every page's content passes through their infrastructure. More on that trade-off below.

Convert: Web to PDF runs 100% locally in your browser. Nothing you convert is ever uploaded anywhere. That's the whole point of the extension — but it also means the unit of work is "one page, one click." For a whole website, you repeat that unit as many times as the site has pages you care about. This guide is about doing that efficiently, not pretending it's automatic.

Step 1: Get your list of pages

Before you convert anything, figure out exactly which pages you need. Trying to "discover as you go" by clicking around wastes time and you'll miss pages. Three ways to build the list, roughly in order of how complete they are:

Check for a sitemap.xml

Most websites — especially anything built on WordPress, Shopify, Webflow, or any modern CMS — publish a sitemap at a predictable URL:

https://example.com/sitemap.xml

Open that in a new tab. You'll usually get one of two things:

  • A flat list of URLs — every page on the site, ready to copy
  • A sitemap index — a list of links to other sitemaps (e.g., sitemap-posts.xml, sitemap-pages.xml), which you click into to get the actual URLs

Paste the URLs into a plain text file or spreadsheet. This is the single fastest way to get a complete, accurate page list for a site — better than clicking through navigation, because it usually includes pages that aren't linked from the main menu (old blog posts, legacy landing pages, paginated archives).

If sitemap.xml 404s, try sitemap_index.xml, or check the site's robots.txt (example.com/robots.txt) — it often has a line like Sitemap: https://example.com/sitemap.xml pointing you to the real location.

Use the site's own navigation

No sitemap? Use the main nav, footer links, and any "all posts" or "archive" index page. Open each top-level section, note the URLs, then drill into subpages from there. Fine for smaller sites (10-20 pages), but tedious and error-prone past that.

Build a manual list

For a defined set of pages rather than a true "whole site" — a competitor's pricing history, one documentation section, a handful of legal pages — just list the URLs by hand as you find them.

Whichever method you use, end up with a plain list of URLs before converting anything. Working from a list means you can check pages off, pick back up if interrupted, and know when you're actually done.

Step 2: Convert each page, one at a time

This is the actual workflow, repeated once per URL on your list:

  1. Navigate to the page. Open the URL from your list in a tab.
  2. If the page uses infinite scroll, scroll down first to load what you want. The extension captures what's currently rendered in the DOM — content you haven't scrolled to yet won't be in the PDF. This matters for long article feeds, product listings, and social-style pages.
  3. Click the Convert: Web to PDF icon in your toolbar.
  4. Choose your capture mode:
    • Article Mode for blog posts, docs, and long-form content — strips navigation, sidebars, ads, and comments down to a reader-friendly view. Good default for content pages. Article extraction can occasionally drop code blocks, so preview before trusting it on technical docs.
    • Standard mode + Remove Elements for more control — click the header, cookie banner, sidebar widgets, or anything else you don't want, and it disappears from the capture, with undo available.
    • Single Page Mode to force a page that would otherwise paginate (long tables, wide layouts) onto one continuous page.
    • Load All Images if the page lazy-loads images below the fold, so you don't end up with blank placeholders.
  5. Preview the PDF before downloading — this is where you catch a missed cookie banner or images that didn't load.
  6. Download, using a filename that will make sense later.
  7. Check the page off your list and move to the next URL.

For pages behind a login — an internal wiki, a client portal, gated documentation — this works exactly the same way, because the extension runs in your actual authenticated browser session. That's something a server-side crawler or cloud "whole site to PDF" tool fundamentally cannot do, since it isn't logged into your account.

Step 3: Organizing the output

You'll end up with one PDF file per page. A few habits that make a 30-page or 200-page archive usable instead of a junk drawer:

Name files consistently

Pick a convention and stick to it for the whole job. Something like:

01-homepage.pdf
02-about.pdf
03-pricing.pdf
04-blog-post-title.pdf

Numbering by the order you converted them (which should match a logical order — see below) keeps the folder sorted the way you'd read the site. If you're archiving for compliance or legal purposes, include the capture date in the filename: 2026-07-08-pricing-page.pdf.

Use subfolders for large sites

For anything beyond a couple dozen pages, mirror the site's own structure in folders: /docs/, /blog/, /legal/, /product/. It's easier to find "the refund policy page from March" in a /legal/ folder than scrolling a flat list of 150 files.

One combined PDF vs. many separate files

Worth being upfront: Convert: Web to PDF does not merge multiple pages into one combined PDF. Each conversion is its own standalone file — real PDFs with selectable text and clickable links, since they're built on Chrome's own print engine, but one file per page, not one file for the whole site.

If your end goal is a single combined document, you'll need a separate PDF-merge step afterward. That's genuinely out of scope here — this is a webpage-to-PDF tool, not a PDF-editing tool. Any standard PDF merge utility can combine the files once you have them.

Order matters more than you'd think

Convert top-level pages first (home, about, main product/service pages), then subpages, then sweep up whatever's left (old blog posts, archived pages, edge cases). A logical order means that if you get interrupted, you know exactly where you left off — "everything down to the 2024 blog archive" is a useful checkpoint; "47 random pages out of 200" is not.

When this workflow is worth doing

Converting an entire site page-by-page is a real time investment, so it's worth being clear on when it earns that time:

  • Legal and compliance archiving — Snapshotting your own site's terms, privacy policy, and pricing pages at a point in time, or archiving a vendor's/partner's site for a dispute or audit trail. A PDF with a capture date is a defensible record in a way a live URL isn't.
  • Research citations — Academic or journalistic work benefits from a local, permanent copy of exactly what a cited page said, since the live page can be edited or removed after publication.
  • Personal backup before a site changes or shuts down — If a service is shutting down, being acquired, or heading into a redesign that will nuke old content, this is your window to grab a full copy.
  • Documentation snapshots — An entire docs site or knowledge base as a point-in-time reference, especially internal wikis and login-gated documentation that public archiving tools can't reach.
  • Competitive or market research — Archiving a competitor's full site (pricing, feature pages, positioning) as it existed at a specific moment.

Set realistic time expectations

Be honest about scale before you start — this is manual, with no background job running while you do something else. A rough budget:

  • Simple content pages (Article Mode, minimal cleanup): 20-40 seconds each once you're in a rhythm.
  • Pages needing Remove Elements cleanup: 45-90 seconds each, since you're clicking off elements before capture.
  • A 10-page site: comfortably done in 15-20 minutes.
  • A 50-page site: closer to an hour, possibly split across two sittings.
  • A 200+ page site: a multi-hour project across a few sessions. Worth asking whether you need every page, or whether a subset (all product pages, all legal pages, the last two years of posts) actually covers it.

If you're staring down hundreds of pages thinking "there has to be a faster way" — there is, but it involves a trade-off, covered next.

The trade-off vs. cloud "whole site" crawlers

Some paid and free online services advertise automatic whole-website-to-PDF conversion: paste in a domain, and their server crawls the site and hands you back a batch of PDFs (or one combined file) without you clicking through each page yourself.

That automation is real, and for genuinely massive sites it can save time. But it comes from a different architecture than a browser extension, and it's worth understanding the trade-off honestly rather than picking a side:

  • Their model: A server-side crawler visits every page on your behalf. That means every page's content — including anything behind a login, if you give it credentials — passes through their infrastructure. You're trusting a third party with the full content of every page you archive.
  • Our model: Nothing leaves your browser. Every conversion happens locally, using Chrome's own rendering and print engine, and nothing is sent to a server. The cost of that privacy is that it's page-by-page, driven by you.

Neither approach is universally "better." A public marketing site with no sensitive content is a reasonable candidate for a cloud crawler if speed matters more than privacy. An internal wiki, a client portal, or anything you wouldn't want passing through an unfamiliar third-party server is a much better fit for a local, page-by-page tool — slower, but nothing ever leaves your machine.

Frequently asked questions

Can this convert a whole website automatically?

No — see above. Convert: Web to PDF converts one page per action; there's no crawler, no batch mode, and no "enter a domain, get the whole site" button. The workflow in this guide (list your URLs, then convert each one) is the real, honest process for covering an entire site.

How do I find every page on a website before converting?

Check for a sitemap at yourdomain.com/sitemap.xml first — it's the fastest way to get a complete URL list and often catches pages the main navigation doesn't link to. If there's no sitemap, work through the site's navigation and any archive/index pages, and build your list manually as you go.

Can I combine all the individual PDFs into one file afterward?

Not with this extension — it converts pages to PDF but doesn't merge multiple PDFs into one. Each page becomes its own standalone PDF file. If you want a single combined document, you'll need a separate PDF-merge tool as a second step after conversion.

Will this work on pages behind a login, like an internal wiki?

Yes, and it's one of the strongest reasons to use this approach for a whole site. Because the extension runs locally in your actual browser session, it can convert any authenticated page you can see — internal wikis, client portals, gated documentation. Cloud crawlers and public archiving tools generally cannot reach those pages at all.

What happens with infinite-scroll pages, like a blog archive or feed?

The extension captures whatever is currently loaded in the page. If a page uses infinite scroll and you haven't scrolled down, you'll only capture what loaded initially. Scroll to load everything you want in the PDF first, then convert.

How long does converting a whole website actually take?

It scales roughly linearly with page count, since each page is a manual step. Budget 20-90 seconds per page depending on how much cleanup each one needs (Article Mode pages are fastest; pages needing manual element removal take longer). A 10-page site is a 15-20 minute job; a 200-page site is realistically a multi-hour project across a few sessions.

Bottom line

There's no shortcut here worth pretending exists: converting a whole website to PDF with a local, privacy-respecting tool means visiting and converting each page yourself. What Convert: Web to PDF gives you in exchange is real PDFs — selectable text, clickable links, clean output with Article Mode and Remove Elements — built locally, with nothing ever uploaded, working even on pages a cloud crawler could never log into. Get your URL list from a sitemap, work through it methodically, name your files consistently, and budget your time honestly for the size of the site. That's the whole process.

Convert: Web to PDF is free on the Chrome Web Store, and works in Chrome, Edge, Brave, and Arc.