Guide

Scanned PDFs: what OCR gets wrong, and how to catch it

Updated

Optical character recognition is good enough now that people trust its output, which is precisely the problem: the errors it makes in tabular data are the ones a human reader will not notice.

The confusions are predictable

0 and O. 1 and l and I. 5 and S. 8 and B. 6 and G. Decimal points and commas that vanish or move.

In prose these are visible: a reader trips over them. In a column of account numbers or amounts they are invisible, because there is no context to make a wrong digit look wrong.

Input quality beats everything

A clean 300 dpi scan of an original document is worth more than any amount of software applied to a phone photograph of a photocopy.

So the first question is not which tool but whether a better input exists. A rescan takes minutes; correcting a bad recognition pass by hand takes hours and never quite finishes.

Three checks that catch most of it

Totals. If the document has a sum, recompute it from the extracted rows. A column that reconciles has probably survived intact.

Field shape. Account numbers, postcodes, dates and reference codes have formats, and a validation pass that flags anything not matching the pattern finds the recognition errors quickly.

A spot check by eye, taken from the middle of the document. The first page is the one that was tested when the settings were chosen.

Treat it as a draft

The useful discipline is to regard recognition output as a draft requiring verification rather than a result. That single framing change is what separates a project that works from one that quietly poisons a dataset.

Where the data will feed something consequential, an accounting system, a report, a decision about a person, budget for the checking rather than hoping it is unnecessary.

One selection test, and you know the route

What happens when you select the text, what the data looks like, and whether it is personal. Three answers.

Run the checker