OCR on scanned PDFs: what it can read, what it cannot, and why DPI matters

There are two completely different kinds of PDF, and telling them apart takes two seconds: try to select a sentence with your cursor. If the text highlights, the document contains real text. If nothing happens, you are looking at pictures of pages and no amount of "extract text" will help, you need OCR.

What OCR is doing

Optical character recognition converts pixels into characters. Modern engines such as Tesseract run roughly this pipeline:

1. Binarisation, convert the greyscale scan to pure black and white, adapting the threshold per region so a shadow across the page does not swallow a paragraph.
2. Deskew and despeckle, straighten a page scanned at an angle, drop isolated specks of noise.
3. Layout analysis, find blocks, then lines, then words. This is where columns, tables and sidebars are identified or misidentified.
4. Recognition, since version 4, Tesseract feeds line images to an LSTM neural network that reads a line as a sequence rather than classifying glyphs one at a time. This is why it handles joined and slightly distorted type far better than older engines.
5. Language modelling, the engine weighs its character guesses against a dictionary and character-sequence statistics for the language you selected. Choosing the wrong language is one of the biggest accuracy losses available, because the model will happily bend words toward the wrong vocabulary.

Resolution is the single biggest factor

OCR accuracy depends on how many pixels make up each character. The rule of thumb the Tesseract project itself gives is around 300 DPI for ordinary body text.

• Below ~200 DPI, small type loses the fine distinctions between similar letters and you start seeing classic confusions: rn read as m, l/1/I, 0/O, 5/S.
• Above ~400 DPI you gain almost nothing and pay for it in processing time and memory.
• For unusually small print, footnotes, legal fine print, receipts, 400–600 DPI helps.

If you are scanning the document yourself, this is the one setting worth getting right. Rescanning at 300 DPI beats any amount of post-processing on a 150 DPI capture.

What wrecks accuracy

• Photographs of screens or paper taken at an angle. Perspective distortion is not the same as skew and is much harder to correct.
• Uneven lighting, especially a phone's shadow across the page.
• Coloured or patterned backgrounds, which confuse binarisation.
• Handwriting. General-purpose OCR is built for printed type. Cursive handwriting recognition is a different problem and mostly a different class of model.
• Complex tables. The characters may be read correctly while the structure, which value belongs to which column, is lost entirely.
• Multi-column layouts, where lines from adjacent columns get interleaved into one nonsense sentence.
• Decorative or heavily stylised fonts, and text over images.

Practical steps for a better result

1. Fix the image before recognising it. Increase contrast, straighten the page, crop away the desk. A ten-second adjustment often does more than any engine setting.
2. Set the correct language, and set multiple languages if the document mixes them.
3. Scan in greyscale, not colour, for plain documents. It reduces noise and file size without losing information the engine uses.
4. Split the job. If only pages 4–7 matter, OCR those pages. Recognition is the slowest step in any document pipeline.
5. Always proofread numbers. Even at 98% character accuracy, a page of figures will contain errors, and a digit error in an invoice total is far worse than a letter error in a sentence.

Expectations, honestly set

A clean 300 DPI scan of a modern printed page in a well-supported language will typically land in the high nineties for character accuracy. A phone photo of a crumpled receipt under a desk lamp will not, and no tool will make it. OCR is a quality-in, quality-out process.

Running it locally

OCR is computationally heavy, which used to be the argument for sending documents to a server. That argument has expired: Tesseract compiled to WebAssembly runs entirely in a browser tab, using your own CPU.

That is how NextTool's PDF OCR and image OCR work. It is slower than a datacentre GPU, and the trade is that your medical records, contracts and ID documents, which is overwhelmingly what people OCR, never leave the machine. Expect a few seconds per page, and expect the first run to pause while the language data downloads.