OCR Explained: How to Make Scanned PDFs Searchable

You scan a stack of documents, save them as PDFs, and later try to search for a name inside one. Nothing comes up. The document clearly contains the word, but the search finds nothing. This is the single most common surprise with scanned PDFs, and OCR is the solution. If the documents started life on paper, capturing them with a phone scanner before running OCR gives the cleanest result.

Why a scanned PDF is not searchable

When a scanner produces a PDF, it does not read the words on the page. It captures a photograph of the page and wraps that image in a PDF. To a computer the page is a picture. There is no text to search, select, or copy, only pixels that happen to look like letters to a human.

This is why a scanned PDF and a digital one can look identical while behaving completely differently. There is a two-second test: open the file and try to select a sentence with your cursor. If you get a neat text highlight, the document has a text layer. If you get a rectangular selection box over the whole area, or nothing at all, you are looking at an image and it needs OCR.

The consequences go further than search. A scanned PDF cannot be meaningfully converted to Word, because there is no text to convert. Screen readers cannot read it aloud, which makes it inaccessible to anyone relying on assistive software. And it will not be indexed properly by any document management system, so an archive of scans is effectively a filing cabinet you can only browse by name.

What OCR actually does

Optical Character Recognition (OCR) analyzes the image, recognizes the shapes of individual characters, and reconstructs the actual text. Crucially, it does not change how the document looks. OCR adds an invisible text layer positioned directly behind the visible page image. The document appears identical, but a real, machine-readable text layer now sits underneath, so search, selection, and copying all work.

That layering is the clever part. The original scan stays exactly as it was, including the coffee stain and the handwritten note in the margin, so the document still looks like the thing you scanned. The recognised text is placed invisibly on top, word by word, positioned over the matching pixels. When you select a sentence, you are selecting the invisible text while seeing the image, which is why the highlight lines up with the words on the page.

How OCR recognizes text

CocoPDF's OCR tool uses a high-accuracy OCR engine. It examines the image, isolates lines and words, and matches character shapes against trained models. Where a shape is ambiguous, such as deciding whether a mark is a capital I, a lowercase l, or the digit 1, it uses the surrounding context and the statistics of the chosen language to decide.

That ambiguity is worth dwelling on, because it explains most of the errors you will see. In many fonts those three characters are nearly identical shapes. So are the digit 0 and the capital O, and the pairs rn and m at small sizes. The engine resolves them by asking what is likely: "Il1inois" is not a word, "Illinois" is, so the middle character is probably a lowercase l. This works well in running prose and much less well on reference numbers, serial codes, and passwords, where there is no linguistic context to lean on. If a scanned invoice number comes out slightly wrong, this is why.

Why language selection matters

That last point explains why choosing the right language before processing has such a large effect on accuracy. Each language model carries knowledge of which letter combinations and words are common. An English model expects English letter patterns, while an Arabic model expects an entirely different script and reading direction.

Run an English document through the Arabic model and accuracy collapses. CocoPDF's OCR tool supports English, French, Spanish, German, and Arabic, so always select the primary language of your document first.

Language affects more than the alphabet. French and Spanish carry accented characters that an English model will tend to flatten, turning é into e and losing the meaning of a word. German compounds words into long strings that a model expecting short words will try to split. If a document is genuinely bilingual, choose the language of the body text rather than the headings, since that is where most of the characters are and where errors cost you the most.

Getting accurate results

• Scan at 300 DPI or higher. Low-resolution scans blur the character shapes OCR depends on.
• Keep pages straight. Skewed or rotated scans reduce accuracy, so straighten them first if needed.
• Use good contrast. Clean black text on a white background works best, and faded or stained documents are harder.
• Pick the correct language before processing.
• Run OCR before compressing. Compression removes image detail, and OCR needs that detail to read the characters.
• Fix the page orientation first with Rotate PDF if pages came out sideways, since a rotated page is largely unreadable to the engine.

What accuracy to expect

On a clean 300 DPI scan of printed text in a common font, modern OCR is very accurate, and the errors that remain are usually in odd places rather than spread through the document. Accuracy falls off sharply with anything unusual: faxes, photocopies of photocopies, tightly set small print, decorative or script fonts, and coloured backgrounds behind text all cost you.

Two categories are worth setting expectations on. Handwriting is a different problem from printed text and general-purpose OCR handles it poorly, so do not plan a workflow around recognising handwritten notes. Tables also tend to disappoint, because OCR reads text but does not reliably reconstruct which cell each value belonged to. If you need the numbers from a scanned table as data rather than as text, expect to check them by hand, and see PDF to Excel for the digital-source case.

The practical implication is that OCR output should be treated as searchable, not as verified. It is excellent for finding the document you need in an archive of hundreds. It is not something to copy a bank account number out of without reading it against the image first.

Where OCR fits in the order of operations

OCR interacts with the other things you might do to a scan, and the sequence matters. Rotate the pages first so they are upright. Run OCR second, while the image still has all its original detail. Compress third, once the text layer exists, because the text layer is stored separately from the image and survives compression intact. Doing it the other way round hands the engine a degraded image and produces a worse text layer permanently.

Also worth knowing: OCR does not need to be repeated. Once a document has a text layer, it keeps it through merging, splitting, and compression. Running OCR twice on the same file does not improve the result and simply adds a second text layer over the first.

Once a document has been through OCR, it behaves like any digital PDF: you can search it, copy from it, and index it. Upload a scanned file to the OCR PDF tool, choose the language, and let the server do the rest.