Firefox has saved pages as PDF for years, and it costs nothing. So the honest question for any capture extension is not whether it works, but when it is worth the trouble at all. I ran the same article through both routes on the same day and counted what each one keeps.
One document: the English Wikipedia article on PDF. Two routes, same URL, same day.
# Route A — the print engine
chrome --headless --no-pdf-header-footer \
--print-to-pdf=out.pdf https://en.wikipedia.org/wiki/PDF
# Route B — screenshot capture, then read back
# (Full Page PDF Snap 2.16.0, single-page output)
pdftoppm -r 150 -png capture.pdf page
OMP_THREAD_LIMIT=1 tesseract page-1.png out --psm 6 -l engBoth results compared against the article's plain text from the Wikipedia API, retrieved the same day.
| Print to PDF | Screenshot capture | |
|---|---|---|
| Pages | 26 | 1 |
| Page breaks | 25 | 0 |
| Breaks cutting a sentence | 9 (36 %) | 0 |
| Words recovered | 9,620 | 8,316 |
| Recall against source | 94.8 % | 92.7 % |
| Text layer | yes | no — OCR required |
| Embedded images | 2 | the page itself |
| File size | 1.1 MB | 6.7 MB |
Read plainly: print wins on text and size, capture wins on continuity. Print keeps a real text layer, needs no OCR, and produces a file six times smaller. It also recovers more words, which is unsurprising — reading text out of a file beats reading it out of pixels.
Nine of twenty-five page breaks fall in the middle of a sentence. Three examples, taken verbatim from the printed file:
page 1 ends: ...displaying pages to any screen and any platform.[8]
page 2 begins: Adobe made the PDF specification available free of c...
page 3 ends: ...D or PRC and various other data formats.[24][25][26]
page 4 begins: File format A PDF file is organized using ASCII char...
page 4 ends: ...e of the new features introduced in version 1.5.[30]
page 5 begins: At the end of a PDF file is a footer containing The ...On a printed sheet a reader bridges that gap without noticing. A parser does not. Feed those twenty-six pages to OCR or a language model and every break is a place where context ends and starts again, with a header, a footer and a page number in between. That is what the single continuous sheet avoids — not by being smarter, but by never cutting.
A Letter sheet with standard margins uses 80 % of its area for content. The remaining fifth is white space that exists because paper needs a grip edge — a constraint from a physical process, applied to a file nobody will ever print. Across twenty-six pages that adds up.
The deeper difference is not the count of pages but what the print engine does to reach it.
Printing hands the page to a layout pass that rebuilds it for paper: columns reflow,
backgrounds are dropped by default, sidebars vanish or repeat, and any
@media print rule the site author wrote takes effect — rules written to
remove navigation, hide interface elements and strip images.
For an encyclopedia article that is mostly harmless, which is why Wikipedia was a fair test rather than a favourable one. For an order confirmation in a customer portal, an invoice view or a support conversation, the print stylesheet is exactly what decides which parts of the screen survive — and it was written by someone else, for a different purpose.
A capture makes no such decision. It photographs what the browser drew.
| If you want… | Use | Because |
|---|---|---|
| the words, searchable, small | print to PDF | real text layer, 1.1 MB, no OCR step |
| the page as it looked | capture | no reflow, no dropped backgrounds, no print stylesheet |
| one uninterrupted input for OCR or an LLM | capture | one sheet instead of 26 fragments |
| a logged-in page a converter cannot reach | capture | runs in your own browser session |
| to archive a hundred pages nightly | print to PDF | seconds instead of two minutes each, a sixth of the storage |
Firefox's built-in export is free and already installed. If it does what you need, it is the right tool and an extension is unnecessary overhead. The case for capture is narrower than its proponents usually admit — and stronger than its critics assume, in exactly the situations where the layout is part of what you are keeping.
For most pages, yes. It keeps a real text layer, produces files around a sixth the size, and needs no extra software. It recovered 94.8 % of the source text against 92.7 % for the capture route. Use it unless you specifically need the layout preserved or an uninterrupted sheet.
Because it has no text layer at all. Every word has to be recovered from pixels by OCR, which introduces errors that reading a file does not. The gap here was 2.1 percentage points — small, but it is a real cost, not a rounding difference.
In this document, 9 of 25 breaks fell mid-sentence. A human reader bridges that; a parser does not, and each break inserts a header, a footer and a page number into the text stream. For OCR pipelines and language models that is the practical difference between 26 fragments and one continuous input.
It stores pixels rather than characters. 6.7 MB against 1.1 MB for the same article. If you archive hundreds of pages, that difference decides the approach on storage grounds alone.
Yes — it runs in your own browser with your session, exactly like a capture does. The route that cannot reach logged-in pages is a server-side converter, which fetches the URL itself as an anonymous visitor. That distinction is covered in a separate measurement.