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.
The figures below were measured against a build without a text layer, and the conclusion drawn from them no longer holds. The capture was version 2.16.0; its 92.7 % came from running Tesseract over the image. The text layer — taken from the page's DOM rather than from recognition — arrived the following day.
Rerun on 5 August with version 2.30.0, same article, same print command,
reading the capture's text layer with pdftotext instead of
recognising it:
| Print to PDF | Capture | |
|---|---|---|
| Recall, against plain-text reference | 99.7 % | 99.9 % |
| Recall, against rendered HTML | 87.6 % | 91.5 % |
| Same capture, read by OCR instead | — | 87.0 % |
Two things follow. Against the plain-text reference the routes are no longer distinguishable — 99.7 against 99.9 — because that reference is only running text, which both take almost completely. Against the stricter reference, which includes infoboxes, tables and captions, the capture leads by 3.9 points. And on the identical image, the text layer is worth 4.5 points over OCR: 91.5 against 87.0. What changed is not the picture but where the text comes from.
The old numbers are withdrawn, not adjusted. The rerun could not reproduce them: against the same kind of reference it gives 99.7 % for print where 1 August recorded 94.8 %, and 98.7 % for OCR where it recorded 92.7 %. That difference cannot come from the product. It lies in the word counting or in how the reference was fetched, and the original raw data describes that only as “Wikipedia REST API plain text”. Rather than correct a figure downward on a guess, the earlier run is left standing as a record of what was done, marked as superseded. Raw data of the rerun · Issue 18
What has not changed: print still produces a far smaller file, and it still breaks sentences across pages. Those parts of the comparison stand.
| 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 as it was written on 1 August: print wins on text and size, capture wins on continuity. The first half of that no longer holds — see the correction above. 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.
These figures as data: get_measurement_data on
the endpoint returns this dataset including the control
run, so a number can be checked without scraping the page for it.