Is Your OCR Good Enough? Testing Scanned PDFs Before They Go on the Website

There are two kinds of scanned PDF. One is a picture of a page. The other is a picture of a page with an invisible, machine-readable transcription sitting behind it, produced by optical character recognition.

They look identical on screen. They behave completely differently for search engines, for site search, for a public records search, and for anyone using a screen reader. Only one of them can be made accessible without redoing the scan.

Test one: is there any text at all?

The fastest check needs no tools. Open the PDF, try to select a line of text with your cursor, and try to search for a word you can see on the page. If selection does nothing and search finds nothing, the file is image-only.

For checking many files at once, extract the text and measure it:

• pdftotext file.pdf - | wc -c — a multi-page document returning a handful of bytes has no real text layer.
• pdffonts file.pdf — an image-only PDF lists no fonts at all.

Run this across a sample of your published documents and you will get a percentage. In the corpora we audit, image-only files cluster hard in material scanned before roughly 2010 and in anything that came from a copier with scan-to-email enabled.

Test two: is the text any good?

Presence is not accuracy. OCR engines report confidence, and vendors report character accuracy, and both of those numbers are friendlier than the reading experience they describe.

Consider what accuracy rates mean on a page holding roughly 2,000 characters:

Character accuracy	Errors per page	Practical effect
99.9%	~2	Effectively clean; search works
99%	~20	Readable; some searches miss
98%	~40	An error every couple of lines; proper nouns unreliable
95%	~100	Search is unreliable; read-aloud is painful
90%	~200	Effectively useless as text

Word accuracy is the number that matters more, and it is always worse than character accuracy, because one wrong character ruins the whole word. A 98% character rate can mean roughly one word in ten is wrong — and if the wrong word is a street name, a parcel number, or a surname, the record has become unfindable.

Test it directly: extract the text for three or four representative pages and read it against the image. You will know within a minute whether the output is usable.

What wrecks OCR

• Low resolution. Below 300 dpi, accuracy falls off sharply. This is the most common root cause and the one that requires rescanning to fix.
• Skew. Pages fed crooked. A few degrees is enough to degrade results measurably.
• Poor contrast. Faded thermal paper, blue-line prints, third-generation photocopies, and colored or shaded form backgrounds.
• Stamps and signatures over text. "RECEIVED" across a paragraph defeats character segmentation.
• Dense tables and multi-column layouts. Text may be captured accurately and then serialized in the wrong order, which is its own failure.
• Handwriting. Standard OCR does not read cursive. Handwritten margin notes will not be captured, and on many older permit files that is where the operative information lives.
• Unusual typefaces. Dot-matrix output, typewriter carbon copies, and decorative fonts on certificates all degrade recognition.

OCR is not accessibility

This is the misunderstanding that costs agencies the most money. A perfectly OCR'd PDF can still fail every accessibility requirement that applies to it.

OCR produces a stream of characters positioned on the page. Accessibility requires structure: headings marked as headings, tables with identified header cells, lists marked as lists, images given alternative text, a defined reading order, a document title, and a declared language. None of that comes out of an OCR engine.

In practice a scanned document needs three passes to be publishable: capture the image, recognize the text, then tag the structure. Scanning vendors routinely deliver the first two and charge for a finished product. See our WCAG checklist for government PDFs for what the third pass has to produce.

A ten-minute sampling protocol

1. Pull 20 documents at random from the delivery or the website. Weight toward older material and toward anything assembled from mixed sources.
2. For each, extract text and check the byte count. Anything near zero is image-only. Record the count.
3. For five of them, read the extracted text of one page against the page image. Note obvious word errors.
4. Check reading order on any page with columns or tables — does the extracted text run in the order a person would read it?
5. Check for a document title in the PDF metadata, not just a file name.
6. Record the results. Two consecutive samples failing the same way is a specification problem, not bad luck.

What to do with what you find

• Image-only, original available: rescan at 300 dpi or better. Re-running OCR on a bad image will not rescue it.
• Image-only, original gone: OCR the existing image and accept a lower accuracy, or re-key the critical fields by hand. For a small number of high-value records, manual transcription is often the cheaper answer.
• Text present but poor: re-OCR with a better engine and correct preprocessing — deskew, despeckle, contrast normalization — before assuming a rescan is required.
• Text good, structure missing: this is remediation, not scanning. It can be automated for most documents.
• Nothing salvageable and low value: consider whether the document needs to be published at all, or whether an accessible summary with the original available on request is the better answer.