How OCR works, and why scans read better than photos
A scanned contract, a photographed whiteboard, a screenshot of an error message: all pictures of text, none of them text. Optical character recognition (OCR) is the step from pixels to characters, and it has gone from a research problem to something a browser does in seconds — the image-to-text tool and PDF OCR run the open-source Tesseract engine on your device. Understanding how it works is the fastest way to get good results from it.
What OCR is and isn't
OCR reads printed characters and outputs a text string. It does not understand the document: it doesn't know a table is a table, a heading is a heading, or that "1" and "l" mean different things except by the shapes and a dictionary. That's why OCR output needs a human read-through for anything that matters, and why the accuracy figures quoted by vendors — 99% on clean print — still mean one wrong character every hundred.
The pipeline: clean, find lines, recognise, check
- Pre-processing. The image is converted to greyscale, thresholded to black and white, deskewed if the page is rotated a few degrees, and scaled toward about 300 pixels per inch — the resolution the engines were trained at. Much of OCR's accuracy is won or lost here.
- Layout analysis. The engine finds blocks, then lines, then words: regions of ink separated by whitespace. Columns and boxes confuse this step, which is why multi-column pages sometimes come out interleaved.
- Recognition. Modern Tesseract (since version 4) runs each line through a recurrent neural network (an LSTM) trained on millions of rendered lines in the chosen language, producing characters with confidences. Older engines matched individual character shapes; the line-based approach handles touching characters and varied fonts far better.
- Language modelling. A dictionary and character statistics settle ambiguities — "rn" versus "m", "0" versus "O" — which is why choosing the right language matters, and why nonsense strings (serial numbers, codes) are read less reliably than words.
Why input quality decides accuracy
The engine can only see what the pixels contain. A 300-DPI flatbed scan of a laser-printed page gives each character about 30 pixels of height with clean edges: near-perfect. A phone photo taken at an angle under a lamp gives characters that shrink toward the far edge, a brightness gradient that defeats thresholding, and blur from a hand-held camera: mediocre. The fixes are all optical: fill the frame, hold the phone parallel to the page, use even light, keep still, and for anything important scan it — the document scanner corrects perspective and contrast before reading, and What DPI you actually need for printing explains the resolution arithmetic.
Searchable PDFs and text layers
A scanned PDF is a picture; a "searchable" PDF is the same picture with an invisible text layer positioned over each word, so search, selection and screen readers work while the page still looks like the scan. That is what office scanners' OCR option produces, and what the searchable PDF tool does in the browser: read each page, place transparent text in the word boxes, save. The text layer is only as good as the OCR — a misread word is a word Ctrl+F won't find.
Handwriting, tables and other honest limits
Tesseract was trained on print. Neat block capitals sometimes work; cursive mostly doesn't, and handwriting recognition is a separate (larger, usually cloud-hosted) class of model. Tables come out as text in reading order, not as cells. Mathematical notation, mixed scripts on one line, and decorative fonts all degrade results. None of this needs a server: the engine and language data (about 9 MB) download once from a CDN, and the images stay on your device — the honest reason to prefer a browser tool for documents you'd rather not upload.
Sources and further reading
The claims in this guide rest on these references, which were checked when the guide was last updated. Spotted an error? The contact page says how to report it.