Optical character recognition is one of those technologies that feels like it should either work or not, and instead works brilliantly on one document and produces gibberish on the next one from the same stack of paper. The variation is not random, and understanding what the engine is actually doing makes the failures predictable rather than mysterious.
A scanned PDF is a picture in a document-shaped wrapper
Start with what a scanner produces, because the misunderstanding usually begins there.
PDF is a container format. It can hold text as text: real character codes, with a font, positioned on the page, which is what happens when a word processor exports a document. It can equally hold a photograph of a page and nothing else. Both are valid PDFs, both open in the same reader, and both look like documents to a human being.
Only one of them is searchable, and it is the same distinction that decides whether extracting text from a PDF returns your document or returns nothing at all. That tool reads the text objects the file already contains. Given a scan, there are none, and an empty result is the correct answer rather than a failure. The quickest test is to try to select a line with your cursor. If nothing highlights, or the whole page highlights as one block, you are looking at an image.
What recognition actually does
The engine’s job is to go from pixels to characters, and it happens in stages.
First the page is separated into regions: what is text, what is a photograph, what is a table or a rule. Then text regions are broken into lines, lines into words, and words into candidate characters. Then each candidate shape is compared against a model of what letters look like in the language you selected. Finally, and this matters more than people expect, the result is reconciled against a dictionary and a model of which letter sequences are plausible.
That last stage is why recognition output has a characteristic failure mode. When the engine is uncertain it does not usually produce a random character; it produces a real word that looks similar to what was there. The classic confusions are between shapes that genuinely resemble each other at low resolution: the digit one against a lowercase l against a capital I, the digit zero against a capital O, rn against m. Those are not arbitrary errors. They are the engine choosing the most plausible reading of an ambiguous shape, which is the same thing you do when reading bad handwriting.
Our own searchable PDF tool runs Tesseract, the long-established open-source engine, compiled to WebAssembly so it runs inside the browser tab. Two things about that are worth recording because they are frequently assumed to be impossible. The engine ships single-threaded core builds, so it does not require the cross-origin isolation headers that would break other parts of a page, and the language training data is fetched at the point you choose a language rather than bundled up front, because those files are large and you only need the one.
The invisible text layer
Making a PDF searchable does not replace the page. It adds to it.
The recognised characters are written into the document as text objects positioned over the words they came from, in a rendering mode that draws nothing visible. The image stays exactly where it was, on top of or underneath depending on the implementation, and the page looks identical. What changes is that a search now matches, a copy now yields characters, and a screen reader now has something to read.
This is why a successful run can feel like nothing happened. The correct outcome is a file that looks unchanged and behaves differently, and the way to verify it is to search for a word you can see rather than to look at the page.
It also explains an oddity people notice when they select text on a converted document: the selection highlight can sit slightly off from the printed letters. The invisible characters are positioned from the engine’s estimate of where each word was, and that estimate is good but not perfect. A small offset is normal and does not indicate a bad conversion.
The input problems no engine can fix
Recognition quality is dominated by the scan, not by the software, and the same handful of problems account for most bad results.
Resolution is the first. Recognition needs enough pixels per letter to distinguish shapes, and the long-standing rule of thumb is around 300 dots per inch for ordinary body text. Below that, the distinguishing features of similar letters stop existing in the data. Upscaling afterwards does not help, because the information was never captured; enlarging a blurry letter produces a larger blurry letter.
Contrast is the second. The engine needs to separate ink from paper, and anything that flattens that separation hurts: a grey photocopy, a highlighter stroke over the text, printing on coloured or patterned stock, a shadow falling across part of the page.
Geometry is the third, and it is the one people most often photograph their way into. A page photographed at an angle has keystone distortion, so letters at the far edge are compressed and skewed relative to those near the camera. Recognition assumes roughly horizontal lines of roughly consistent letters, and a leaning page violates both.
That last problem is exactly what a document scanner is for, and it is worth understanding that the correction is geometric rather than cosmetic. Marking the four corners of the page lets the tool compute a projective transform, the mapping that takes your leaning quadrilateral onto a clean rectangle, and then rebuild the page through it. The output is a flat, square-on page of the kind recognition was designed for. Running that step before recognition, rather than hoping the engine copes, is the single largest quality improvement available to anyone working from photographs.
Its enhancement modes matter for the same reason. A pure black-and-white threshold produces exactly the high-contrast input recognition likes, but it does so by measuring the page’s own average brightness and cutting every pixel to one side or the other. That adapts to how bright your particular photo came out, but it is one global decision for the whole page, so a hard shadow across a corner can wash that corner out entirely. When lighting is uneven, a plain greyscale conversion often recognises better than an aggressive threshold, because it preserves the letter shapes in the shadowed region instead of destroying them.
When the page is a picture rather than a document
Not everything worth recognising is a document. A photograph of a sign, a screenshot of an error message, a receipt, a slide from a presentation: these are single images rather than paginated files, and extracting text from an image is the right entry point. The engine is the same; only the wrapper differs.
Expectations should differ too. A screenshot is usually an easy case, because the text was rendered digitally at a known size with perfect contrast and no distortion, and results are often essentially perfect. A photograph of a sign is a hard case, because it has perspective, uneven lighting, decorative lettering and a background. Neither result says much about the engine.
What to check before blaming the software
If a run comes back poor, work through the input in order. Is the text actually large enough in pixels, or was the scan made at a low setting? Is the page flat and square-on, or is it a photograph that needs flattening first? Is the contrast genuinely strong, or is this a grey generational photocopy? Was the correct language selected? And is the source a photograph of text at all, or a document that already had a text layer you could have extracted directly?
Most disappointing results resolve to one of those, and all but the last are fixed by rescanning rather than by trying a different engine.
