What decides OCR quality on a scanned PDF

What OCR is actually doing

A scanned PDF is a stack of images with no text in it. Turning that into readable characters is not one operation but a chain of them: the page is segmented into text and non-text regions, lines are found within the text regions, lines are split into word and character boxes, each box is passed to a classifier, and the classifier's candidates are then filtered through a language model and dictionary.

The important property of a chain is that errors propagate downward. Get the page segmentation wrong and the lines are wrong; get the lines wrong and the character boxes are wrong. No classifier, however good, returns the right answer for a badly cropped box. That is why OCR quality is usually decided by the image you hand over rather than by the engine you hand it to.

Six things that decide the outcome

1. Scanning resolution

A classifier needs the letter to occupy enough pixels to be distinguishable. At 300 DPI, the lowercase body of 10 point text is roughly twenty pixels tall, which is enough to carry the difference between "e" and "c", or between "rn" and "m". At 150 DPI that height falls below ten pixels and thin strokes start to touch. The Tesseract documentation recommends at least 300 DPI for this reason.

Upscaling a low-resolution scan afterwards does not bring back what was lost. Interpolation invents pixels, not detail: two strokes that merged at capture time are still merged, just larger. Scaling helps only when an image is so small that the engine is working below the size it expects. The real fix is to rescan at the right resolution.

2. Binarisation

Most engines reduce the page to black and white first. A single global threshold falls apart on unevenly lit pages: photograph a document on a desk and one corner sits in shadow, where the letters drop below the threshold and vanish completely. Adaptive, region-local thresholding rescues those pages. Show-through from the reverse side of thin paper is decided at the same step: set the threshold slightly low and the text printed on the back joins the text on the front.

3. Skew and page curl

Line finding usually relies on a horizontal projection profile, the count of dark pixels per scan row. Skew of a degree or two smears the peaks in that profile and two neighbouring lines can merge into one. Book scans add curl near the spine, which produces the same failure on part of the page only, so the middle of a column reads cleanly while the inner margin degrades. Deskewing is the cheapest and most effective thing you can do before recognition.

4. Compression artefacts

JPEG leaves ringing around sharp edges, and text is nothing but sharp edges. On a page scanned as a low-quality JPEG, a grey haze forms around each letter, and the binarisation step either absorbs that haze into the glyph or eats into the stroke. For document scanning, a lossless or high-quality setting beats an aggressive JPEG of the same file size every time. Leave compression for the archiving stage: shrinking the PDF after the text layer exists does not affect recognition.

5. Language data and dictionary

The classifier proposes several candidates per character and the language model picks among them. Choosing the wrong language turns that correction layer into a liability. Run a German document with English data and umlauts drift towards bare vowels; run a French one and accented characters are pulled towards their unaccented neighbours, because the model does not expect them. For mixed-language material, loading both language packs works better than forcing one.

6. Page layout

On a multi-column page, reading order is a segmentation decision. If the columns are not detected, lines get joined left to right and two columns interleave into nonsense. Tables, footnotes, marginalia and watermarks are resolved at the same step. When layout analysis fails, the output is unusable even if every character was recognised correctly. For tables specifically, the follow-on problem is covered in the article on pulling tables into Excel.

The document itself is a variable

Two pages captured on the same scanner at the same settings can give very different results. Clean serif body text is the easiest possible input. Condensed faces, script-like headings, full lines of capitals and underlined text all make it measurably harder, because an underline touching the descenders merges character boxes together. Six point footnotes can disappear word by word on a page whose body text reads perfectly.

The physical condition of the paper is the second variable. A photocopy of a photocopy loses contrast and thin strokes with each generation; stamps and signatures crossing the text stop recognition dead in that region; hole punches and fold lines behave like false line boundaries during segmentation. None of these are fixed by tuning the engine, only by obtaining a better copy.

How to judge the output

OCR output looks confident. The engine hands you prose and does not mark the words it was unsure about. A rough checklist catches most of the damage.

• Check the numbers first: dictionary correction cannot help them. Confusions between 0 and O, 1 and l, 5 and S, 8 and B concentrate here, and these are the expensive errors.
• Compare the volume: the length of the extracted text should roughly match the words visible on the page. A large shortfall means a region was never recognised.
• Select some text: in a searchable PDF the invisible text layer is positioned over the image. If the highlight box does not sit on the word you clicked, the alignment is off.
• Search for known terms: pick a handful of phrases you know appear, and see which ones fail. That tells you where the errors cluster.
• Read the edges: first and last lines sit closest to the crop and suffer first.

Fix the input, not the output

Correcting recognition errors by hand always costs more than capturing a better image. With paper in hand, scan at 300 DPI in greyscale with light compression; colour adds no information for text and a great deal of file size. Shooting with a phone, aim for even lighting and a square angle, and let the document scanner correct perspective and trim the edges. To judge a PDF you already have, render a page to an image and inspect it at one hundred percent: if the letter edges are already mushy, the text layer will be too.

When the input is as good as it is going to get, PDF OCR adds a searchable text layer to the page. The layer is invisible and sits over the image, so the document looks exactly as it did before.

One privacy consequence

Making a document searchable writes a second copy of its contents into the file. Redaction then has to deal with both copies: drawing a black rectangle over the image removes neither the pixels beneath it nor the invisible text layer that mirrors them. That is the subject of the redaction article. Worth restating here too: the PDF tools on this site upload your file to a server for processing, which is a factor to weigh for sensitive material.