Scanned PDF Sample — Pages That Are Pictures
This file looks like a normal text document and extracts like a photograph of one — because that's what it is. Each page is a single JPEG rendered at 150 DPI on a warm paper-toned background, with no text layer whatsoever. It's the file that separates tools which read text from tools which only appear to.
Why an image-only PDF is a different beast
A born-digital PDF stores text as text: fonts, character codes, positions. A scanned PDF stores pixels. Both display identically, but everything downstream diverges: text extraction returns nothing, search finds nothing, screen readers see silence, and copy-paste selects a rectangle of air. Roughly speaking, this is the single most common "why doesn't it work" in PDF processing — the pipeline was built on born-digital files, then a scan arrives.
We verify the property mechanically on every build: the text layer must extract as exactly zero characters, and the rendered page must contain visible dark pixels (so it's a picture of text, not a blank page). That double-check is what makes it a trustworthy negative control.
What to test with it
- OCR, obviously — run it through OCR and compare the recovered text against the born-digital equivalent; the page wording is the same family of paragraphs, so accuracy is easy to eyeball.
- The extraction failure path — what does your code do when extraction legitimately returns an empty string? Crash, silently produce an empty file, or tell the user "this looks scanned — try OCR"? The third is correct, and this file is how you build that detection.
- Scanned-vs-digital detection — a good heuristic: render a page, extract its text; lots of ink but zero characters means scan. This file is the true-positive case for that classifier.
- Compression behavior — unlike the incompressible size samples, JPEG pages respond well to downsampling; compress should achieve real reduction here.
- Search UX — searching this file must return zero hits gracefully, ideally with a hint about why.
How it was made (honestly)
No scanner was involved: a born-digital 3-page document is rendered to canvas via pdf.js at 150 DPI, JPEG-encoded at quality 82 over a paper-toned background, and reassembled as image-only pages. That gives the two properties that matter for testing — pixels instead of text, JPEG artifacts — with a reproducible build. What it does not emulate: skew, coffee stains, hole punches, or the 3° tilt of a real office scanner. For OCR robustness testing against physical-world noise, you still need real scans; this file tests the structural difference, which is the one that breaks pipelines.
FAQ
Why does copy-paste select nothing?
There's nothing to select — the page contains one image object and no text objects. That's the defining property, not a defect.
Can I make it searchable?
Yes — that's what OCR does: it recognizes the pixels and adds an invisible text layer behind the image. The result looks identical but extracts, searches and screen-reads like a normal PDF.
Why 150 DPI and not 300?
150 DPI keeps the file at 422 KB while remaining comfortably OCR-able — modern engines handle it fine. Real archival scanning uses 300+; if you need that, the generator exposes the scale factor as one constant.
Is a PDF "scanned" or "image-only" the same thing?
In practice yes: "scanned PDF" is the colloquial term, "image-only PDF" the precise one. A scan that's been OCR'd is technically both an image PDF and searchable — the categories overlap once a text layer is added.