How to OCR a PDF

Recognition works on the shape of each character, and shape needs pixels. The working rule is that a lower-case letter wants something like 20 to 30 pixels of height for a recogniser to distinguish it reliably. For ordinary body text around 10 to 12 points, that lands at approximately 300 DPI.

Below it, accuracy falls away and it falls away on specific confusions: the thin gap that separates rn from m disappears, and 8 versus B, 0 versus O, 1 versus l and comma versus period all become guesses. At 150 DPI a clean page of large type may still do well, while anything small or slightly soft degrades sharply.

Above it there is very little to gain and real cost to pay. At 600 DPI the character shapes are no better defined for the model’s purposes, while each page carries four times the pixels — four times the memory and processing time, which in a browser tab is the difference between finishing and running out of room.

If you are doing the scanning, scan at 300 DPI. If you were handed a 150 DPI scan, run it and read the output rather than upscaling: interpolating pixels invents detail and does not recover character shapes that were never captured.

Skew is the most damaging and the most common. Recognisers work along text lines, so a page rotated even a couple of degrees means a line drifts across the row of pixels being analysed and characters are sliced. A scan straight in the feeder is worth more than any setting.

Low contrast is next. A faded photocopy, pencil, or a scan with the brightness pushed so that grey text sits close to grey paper leaves the engine unable to separate ink from background cleanly. High contrast — dark ink, white paper — is what the models were trained on.

Noise works against you in the same way: speckle from a dirty platen, JPEG artefacts from an over-compressed scan, show-through from the reverse of a thin page. Each adds marks that can be read as punctuation or can break a character apart. This is one reason to OCR before compressing rather than after — recognition wants the cleanest pixels available.

Then there are the genuinely hard cases. Handwriting will not work: the models are trained on print, and cursive in particular produces nothing useful. Decorative and script typefaces are unreliable for the same reason. Coloured or textured backgrounds behind text interfere with the separation of ink from paper. Very small print, footnotes and dense tabular figures push character heights below what the pixels can support.

A page has no reading order recorded anywhere — it is an image, and an image is a grid of pixels with no notion of which region is a column. Reading order has to be inferred from layout, and the inference that works for the overwhelming majority of documents is to read across and then down.

On a single-column page that is exactly right. On a two-column page it is exactly wrong: the engine takes the first line of the left column, then the first line of the right column, then the second line of the left, and so on, producing text that alternates between two unrelated sentences. The characters are usually recognised correctly; it is the sequence that is broken.

Newspaper layouts, academic papers, brochures and anything with sidebars or pull quotes all hit this. Pull quotes and captions are a related problem: floating text gets spliced into the middle of the paragraph it happens to sit beside.

There are two practical responses. If you only need the document searchable, it does not matter much — each word is still in the right place on the page, so a search finds it and highlights the correct region. If you need the text as a continuous document, either accept that you will be reordering it by hand, or crop the page into columns and recognise each separately so the reading order is unambiguous.

A clean 300 DPI scan of ordinary printed text in a supported language, straight and high contrast, recognises well enough to be genuinely useful. A faded, skewed, low-resolution scan of small print does not, and no amount of tweaking will change that — the information is not in the pixels.

We will not quote an accuracy figure, because any single number is meaningless without the document it refers to. The same engine can be near-perfect on one page and unusable on the next, and a vendor quoting one number is describing their best-case test set.

So build proofreading into the plan for anything consequential. The errors that matter are in numbers, names and codes — exactly the content where a single wrong character changes meaning and where a human reading for sense will not notice.