A PDF made by a scanner is a photograph of a piece of paper. It looks like a document to a person and like a picture to a computer. Nothing in it can be searched, selected, copied, indexed by Google, or read aloud by a screen reader until a separate step called OCR — optical character recognition — looks at the picture, works out which shapes are letters, and writes an invisible text layer underneath.
That step is optional. It is frequently skipped. And because the resulting file looks completely normal, nobody notices until someone goes looking for a word.
The thirty-second test
Open the PDF in any viewer and press Ctrl+F (Cmd+F on a Mac). Search for a word you can plainly see on the page — not a heading, which might be part of a logo, but an ordinary word from the middle of a paragraph.
- It finds the word. There is a text layer. It may still be a bad one — see below — but it exists.
- It finds nothing. The page is an image. Everything downstream that depends on text is broken for this file.
A second tell: try to select a sentence with your cursor. If you get a blue rectangle over the whole page instead of a text selection, you are dragging across a picture.
File size is a decent rough filter at scale. A page of real text is a few kilobytes. A scanned page image is hundreds. If a 40-page document is 30 MB, it is almost certainly image-only. This will not tell you about any single file with certainty, but it will sort a corpus of ten thousand into "probably fine" and "look at these first" in about a minute.
Why the text layer is missing
In our experience the cause is almost never exotic. In rough order of how often we see it:
OCR was switched off on the device
Multifunction copiers have a scan-to-PDF setting with OCR as an option, and on many models it ships disabled because it makes scanning slower. One clerk's copier configured that way will quietly produce image-only PDFs for years. Every document that department published in that period has the same defect, and they all look fine.
This is worth checking before you remediate anything, because if the device is still misconfigured you will be fixing the backlog while the front door keeps adding to it.
The file was printed to PDF from a scan
Opening a scanned image and printing it to PDF produces a PDF whose only content is that image. The "print to PDF" step does not add text; it wraps whatever was on screen.
The original had a text layer and lost it
Some redaction workflows, some flattening tools, and some "reduce file size" operations rasterize the page — they convert everything, text included, into a single image. The file gets smaller or safer and stops being searchable. Flattening a form to prevent edits does this routinely.
OCR ran and failed
OCR on a skewed, faint, or heavily stamped page can produce a text layer that is technically present and practically useless. Ctrl+F finds nothing not because there is no text but because the text says rn1nutes where the page says minutes.
Why it matters more than it looks
An image-only PDF is not a cosmetic problem. Four separate things break at once:
| What breaks | Consequence |
|---|---|
| Screen readers | The document is silent. A blind resident gets nothing at all — not partial access, none. |
| Site search | The document cannot be found by anyone looking for what is in it. |
| The page contributes no indexable content, so it never surfaces in search. | |
| Records requests | Staff cannot search the archive, so a request that should take minutes takes days of manual reading. |
The accessibility consequence is the one with legal weight, and it is also the one people underestimate. A remediation tool can add tags, set a language, fix the reading order and produce a document that passes a structural check while remaining completely unreadable, because there is no text under the tags to read. Tagging an image-only PDF does not make it accessible. It makes it a well-organised picture.
Fixing it
The repair is to run OCR and then verify the result — both halves matter, because unverified OCR is how bad text layers get published with confidence.
- Fix the source first. Turn OCR on at the device or in the scanning workflow, so tomorrow's documents do not join the backlog.
- Work from the original if you still have it. OCR quality depends heavily on image quality, and a 300 DPI original will read far better than a downsampled copy of it.
- Re-OCR the backlog. This is a batch operation, not a per-file one. Sort by how often a document is actually requested rather than by date — the twenty documents your staff search every week matter more than four thousand nobody has opened since 2011.
- Sample the output. Do not trust a completion message. Pull a random handful, search for words you can see, and read a paragraph of the extracted text against the page.
- Then tag for accessibility. Structure work belongs after the text layer is real, not before.
A note on what "98% accurate" means. Vendors quote character accuracy. At 98%, a 2,000-character page carries about 40 wrong characters — enough to corrupt a name, an address, or a dollar figure on nearly every page. We wrote about how to test this properly in Is Your OCR Good Enough?
What to require from a scanning vendor
If someone else is doing the scanning, put the text layer in the deliverable specification rather than assuming it. Useful things to require:
- A searchable text layer on every page, not "where feasible".
- A minimum scanning resolution, and colour or greyscale for anything with a stamp, signature or photograph.
- Deskew and despeckle before OCR.
- A sampling protocol you run on delivery, with a defined threshold for rejecting a batch.
- The right to send a batch back. Without this the specification is a wish.
Our guide to running a backfile scanning project covers the rest of the deliverable in more detail.
Finding them all
The hard part at an agency scale is not fixing one document, it is knowing which of your documents have the problem. Nobody has time to open ten thousand PDFs and press Ctrl+F.
That is the job SentraCheck does first: it walks the documents you already publish, checks each one for a real text layer, and gives you the list — sorted, counted, and separated from the files that are genuinely fine. You can then decide what to re-scan, what to re-OCR, and what to leave alone.