Sample Scanned PDF Generator
Generate a realistic fake-scanned PDF for OCR and image-upload testing — skew, grain, uneven lighting and scan artifacts on a rendered document, with an optional invisible text layer or a genuinely image-only file with nothing selectable at all. Runs entirely in your browser.
Quick Tips for a Believable Fake Scan
Features
It Was Never Actually Scanned
There's no scanner anywhere in this tool, and no camera. What looks like a photograph of a document is a canvas drawing — text, lines, a checkbox or two — rendered pixel by pixel in your browser, then deliberately roughed up: rotated a degree or two off true, dusted with grain, shaded unevenly like a scanner bulb that's past its best years, and finally flattened into a single JPEG and dropped into a PDF page. The PDF itself is completely ordinary. What makes it behave like a scan is that there's exactly one object on each page — a picture — and, by default, nothing else.
That distinction is the entire reason this exists as its own tool rather than a content type inside Sample PDF File. That generator produces real, selectable vector text on purpose. This one produces the opposite on purpose — a file that looks readable to a human and is structurally illegible to anything that isn't running optical character recognition against it.
The degradation isn't cosmetic. Skew rotates the whole page image a degree or two before it's flattened, the same misalignment you get from paper that shifted slightly on a flatbed scanner bed. Grain overlays real per-pixel noise, not a filter applied after the fact. Uneven lighting shades one side of the page darker than the other, mimicking a scanner bulb losing brightness unevenly across its length. Each of these is something a real OCR engine actually has to contend with, which is the whole reason to bother simulating them rather than handing OCR software a perfectly clean render and calling the test done.
What's Actually on the Page
Business Letter and Contract lean formal — letterhead, a dateline, numbered clauses, a signature rule at the bottom — the kind of typed correspondence that ends up scanned into a document-management system years after it was printed. Invoice is deliberately plainer: a billing header, a line-item table, a total, styled like something run off a shared office printer rather than professionally designed.
Filled Form and Plain Text cover the two extremes of what OCR software actually struggles with. Filled Form has ticked checkboxes and a wavy, hand-drawn-style scribble standing in for handwriting — the irregular, non-typeset marks that typeset-only OCR models often fumble. Plain Text is the opposite: dense, uninterrupted paragraph copy, the closest thing here to a scanned page from an actual printed book or report, and the shape of input most general-purpose OCR benchmarks are built around.
Every template writes ToollyX in as the fictional business behind the document — the letterhead, the invoice's billing line, the contract's named party — so what comes out reads as a plausible piece of real-world correspondence rather than obviously placeholder filler, without it being anyone's actual paperwork.
Fed With or Without an Answer Key
Include OCR Text Layer is the one switch that changes what kind of test this file actually is. Leave it off and the PDF is genuinely blind — one image per page, nothing underneath it, exactly what a scanner hands you before any software has touched it. That's the file to use when the question is "does my OCR pipeline correctly extract text from this," because there's no shortcut available; whatever text comes out had to actually be read from the pixels.
Turn it on and a second, invisible layer of text gets added underneath the same image, roughly aligned to where the real words sit but rendered at zero opacity — the same trick a "searchable PDF" export from a scanning app uses. That's a different, equally legitimate test: does your code correctly detect and use an existing text layer instead of trying to re-OCR an already-processed file, which is wasted work at best and a source of duplicate or conflicting text at worst if handled wrong.
Who's Actually Testing With Fake Scans
Teams building document-processing pipelines — invoice extraction, ID verification, claims intake — need scanned-looking input that never touches a real person's paperwork, and a generator that can dial degradation up or down on demand beats waiting for someone to mail in a crooked photocopy. Mobile developers building a "scan with your camera" feature use it to test how their image-cleanup step handles skew and uneven lighting before a real user ever photographs anything. And QA teams validating upload logic specifically need a file that's confirmed image-only, to make sure their "this looks like a scan, route it to OCR" branch actually fires instead of silently falling through.
It also shows up further from document processing than you'd expect — accessibility engineers testing a screen reader's fallback behavior on genuinely unreadable PDFs, and technical writers who just need a realistic-looking "scanned attachment" for a support-ticket mockup without scanning an actual piece of paper to get one.
Where the Illusion Breaks Down
This generator produces something that looks and behaves like a scan structurally, but it isn't a substitute for testing against real scanned input entirely — actual scanner hardware introduces failure modes (torn pages, staple shadows, genuinely illegible handwriting, ink bleed-through from the reverse side) that a synthesized image can approximate but not perfectly reproduce. Treat it as a fast, private first pass, not the last test before shipping a production OCR pipeline.
A few practical notes: very high page counts at High resolution take noticeably longer to generate than the same count at Draft, since every page is a full-resolution image render, not a few lines of vector text — for large batches, Standard resolution is usually the better trade-off between realism and speed. And exactly like the site's other sample generators, Custom file size lands exactly on target without a password, and rounds up by no more than about 15 bytes — never down — with Password Protection on, since AES-256's block padding isn't something any tool can avoid.
One more thing worth knowing: because every page is a JPEG under the hood, Image Quality has a bigger effect on file size here than almost any other setting on this page — dropping from 90% to 50% can shrink a multi-page file dramatically, which is worth remembering before reaching for Custom size mode to solve a problem that a quality adjustment would fix more naturally.