Full Page PDF Snap → Webpage to PDF for OCR
Feeding a web page into OCR or a language model usually means turning it into a PDF first. But a screenshot PDF has no text layer — everything has to be read back from pixels. So how much of the original survives that round trip? I measured it against the source text instead of guessing.
The test subject is the English Wikipedia article on PDF, captured as a single continuous PDF with a full-page capture extension. The resulting file has one characteristic that matters here:
pdftotext returns exactly one characterThat second point is the whole problem. A printed-to-PDF page keeps its text and can be searched directly. A screenshot PDF is a picture: every word has to be recovered by OCR. The question is how much gets lost on the way.
As ground truth I pulled the same article's plain text from the Wikipedia API — 10,285 words. That is what the OCR result gets compared against.
Rendered at 150 dpi and run through Tesseract, the screenshot yields 10,343 words against 10,285 in the original. After normalising both sides (lowercase, punctuation stripped, words under three characters dropped):
| Measure | Value |
|---|---|
| Distinct words in the source | 2,184 |
| Distinct words in the OCR output | 2,364 |
| Recall — source words found in the OCR | 92.6 % |
| Five-word phrases recovered verbatim | 73.9 % |
| Control: unrelated words found in the OCR | 0.0 % |
That last row is not decoration. Before trusting any of the numbers above, the method has to fail where it should: a set of words that never appear in the article scores 0.0 %. If it had scored 30 %, the whole measurement would be noise and the 92.6 % would mean nothing.
Aggregate scores hide the interesting failures. Standards, years and product names are
what people actually extract from documents, so I checked them individually:
ISO, 32000, 1993, Adobe,
PostScript, JavaScript, encryption,
Acrobat — all eight recovered correctly.
The gap between 92.6 % recall and 73.9 % phrase accuracy tells you where the errors sit: not in the body text, but at the edges. Navigation labels, sidebar fragments and interface text get mangled or invented, which is also why the OCR output contains more distinct words than the source.
This is the part with practical consequences. Same excerpt, four rendering resolutions, measuring how many recognised words are real words from the article:
| Resolution | Words | Real words | Garbage | OCR time | Image |
|---|---|---|---|---|---|
| 72 dpi | 860 | 21.3 % | 78.7 % | 2.7 s | 0.8 MB |
| 110 dpi | 1,096 | 92.7 % | 7.3 % | 3.1 s | 1.6 MB |
| 150 dpi | 1,099 | 98.4 % | 1.6 % | 4.6 s | 2.9 MB |
| 220 dpi | 1,099 | 98.7 % | 1.3 % | 5.9 s | 5.2 MB |
Below 110 dpi everything falls apart. Going from 110 to 72 dpi does not degrade the result gradually — it destroys it. Four out of five recognised words become garbage. If you are rendering thumbnails and wondering why OCR returns nonsense, this is why.
Above 150 dpi you are paying for nothing. The jump from 150 to 220 buys 0.3 percentage points for 29 % more time and an image nearly twice the size. 150 dpi is the point where quality stops improving and cost keeps rising.
Everything above runs with two standard tools. No services, no accounts, nothing leaves the machine:
# render the PDF to an image at 150 dpi
pdftoppm -r 150 -png capture.pdf page
# OCR it — the thread limit matters, see below
OMP_THREAD_LIMIT=1 tesseract page-1.png out --psm 6 -l eng
# compare against the source text
python3 compare.py ground_truth.txt out.txt
OMP_THREAD_LIMIT=1 is not cosmetic. Tesseract multithreads internally, and
on batch jobs that internal parallelism fights whatever parallelism you add on top —
running it single-threaded and parallelising across files is measurably faster.
For scale: rendering the full 11,008-point sheet at 150 dpi took 30 seconds and produced a 1459 × 22934 pixel image at 22 MB. OCR over that took 90 seconds. Long single-page captures are cheap to make and expensive to read — worth knowing before you queue up a few hundred.
A screenshot PDF is a faithful visual record but a poor search target on its own. Run OCR once at 150 dpi and store the text alongside the PDF. You then have both: the picture as evidence, the text for finding it again.
The single continuous sheet matters more than it sounds. A page split into A4 sheets cuts tables and paragraphs at arbitrary points, and every cut costs context. One uninterrupted image keeps the reading order intact.
73.9 % phrase accuracy means roughly one in four five-word sequences comes back imperfect. Use the OCR text to locate a passage, then read the wording off the image itself. Never paste OCR output into a citation unchecked — this holds for any OCR engine, not just this one.
6.7 MB for one article, against maybe 80 KB for the same text printed to PDF. No text layer, so every search needs OCR first. And 90 seconds of processing where a text PDF needs milliseconds. If you only care about the words and not how the page looked, printing to PDF is the better tool — this measurement is about the case where the layout is part of the evidence.
150 dpi. Measured on this document, 150 dpi yielded 98.4 % real words against 92.7 % at 110 dpi and 21.3 % at 72 dpi. Going above 150 gained 0.3 percentage points for 29 % more processing time and nearly double the image size.
Almost always because the image was rendered too small. Below roughly 110 dpi recognition does not degrade gradually — it collapses. At 72 dpi, four out of five recognised words in this test were garbage.
92.6 % of the source vocabulary was recovered in this measurement, and all eight checked critical values (standard numbers, years, product names) came back correctly. Exact five-word phrases fared worse at 73.9 %, with most errors in navigation and interface fragments rather than body text.
No. A screenshot PDF has no text layer at all — pdftotext returned exactly one character for the test file. Everything has to be recovered from pixels first.
Print to PDF if you only need the words: it keeps the text layer, needs no OCR and produces a file roughly a hundredth the size. Screenshot capture if the layout itself matters, because printing rebuilds the page and moves things.