How OCR reads text — the mechanism and its limits

Each page of a scanned PDF is a photograph. Your eye sees letters; the computer sees an array of light and dark pixels — nothing searchable, nothing copyable.

OCR (optical character recognition) finds letter shapes in that pixel array and converts them to text data. Lay that text invisibly behind the image and you get a “searchable PDF”: looks exactly like the scan, but search and copy work.

OCR runs roughly like this: clean the image (deskew, despeckle), separate text regions from graphics, split text regions into lines and characters, then classify each fragment. Modern engines classify with neural networks and use surrounding context to settle ambiguous characters.

Knowing the stages tells you where failures happen: tilted scans fail at line splitting, tables fail at region separation, and faint print fails at classification.

The same engine swings dramatically with input. Clean printed text scanned at 300dpi or better exceeds 99% recognition; low-resolution faxes, crumpled receipts, and forms with handwriting mixed in drop sharply.

So the most effective accuracy upgrade isn't a different engine — it's better input. Scan at 300dpi or above, square on the platen, evenly lit. It's also why scans beat phone photos: consistent lighting and angle.

Scripts with large character sets — Korean syllables, CJK ideographs — multiply the lookalike pairs an engine can confuse, and mixed-script documents raise the difficulty further.

Where digits and Latin letters mix, the classics persist: 0 and O, 1 and l, 8 and B. For documents where numbers carry the meaning — account numbers, registration numbers, amounts — OCR output digits must be verified against the original, every time.

The useful distinction is search versus transcription. For finding files by keyword in an archive, 95% accuracy is plenty — a few wrong words still leave others to match.

Reusing OCR text in new documents (quoting contract clauses, migrating table data) is another matter: 5% error means one wrong character in twenty. There, OCR is a first pass that saves typing, and proofreading against the original is part of the job, not optional.

Accurate OCR engines rely on large recognition models. Running entirely in the browser — no server — means downloading and executing the whole model locally, which quickly exceeds practical load times, especially for large character sets like Korean.

That's why browser-local tool sites are cautious about offering OCR. When you use a server-based OCR service instead, the corollary is worth remembering: your document does go to a server — judge its sensitivity accordingly.