Scanned PDF vs text PDF: what OCR really does

Guides · Updated 12 August 2026 · 8 min read

Two PDFs can look identical on screen and be completely different files. One contains text; the other contains a photograph of text. Nearly every "why can’t I search this document" problem comes down to which one you are holding.

Three kinds of PDF that look alike

In practice you will meet three varieties:

• A native text PDF, exported from a word processor or layout tool. The page is built from text-drawing instructions and vector shapes. Text is selectable, searchable and razor sharp at any zoom. Typically small.
• An image-only PDF, produced by a scanner or a camera. Each page is a single picture wrapped in a PDF. Nothing is selectable, nothing is searchable, and zooming in reveals pixels. Typically large.
• A searchable image PDF, sometimes called a sandwich. The scanned picture is still there and is still what you see, but OCR has added a layer of invisible text positioned over the corresponding words. You see the scan and search the text layer. This is what document management systems produce, and it is the format most people actually want.

Telling them apart takes five seconds: try to select a line of text. If nothing highlights, it is image-only. If a selection appears exactly over the words but the characters still look like a scan, it is a sandwich. If the text is crisp and selects cleanly, it is native.

What OCR does, step by step

Optical character recognition turns pixels into characters through a pipeline that is worth knowing, because each stage is where a particular kind of error comes from:

1. Pre-processing. The image is straightened (deskewed), converted to greyscale or pure black and white, and cleaned of speckles. A page scanned at a slight angle is corrected here — or, if the correction fails, everything downstream suffers.
2. Layout analysis. The engine finds the structure: which regions are text, which are images or tables, where the columns are and in what order they should be read. This is where a two-column article can come out interleaved line by line, and where table cells lose their rows.
3. Segmentation. Text regions are cut into lines, then words, then usually individual characters. Touching or broken characters — common on photocopies and old faxes — cause errors here.
4. Recognition. Each shape is classified, historically by feature matching and today by neural networks that read whole lines at once. The engine produces candidates with confidence scores rather than certainties.
5. Language modelling. Candidates are checked against a dictionary and a model of the language, which is what lets the engine prefer a real word over a shape-similar non-word. It is also why setting the wrong language degrades results sharply, and why proper nouns, reference numbers and part codes are recognised worst — no dictionary can help them.
6. Output. The recognised text is written back as a text layer with each word positioned over its image, drawn in invisible rendering mode so it is selectable but not visible.

What makes OCR accurate, and what wastes effort

Accuracy is decided almost entirely before recognition starts:

• Resolution: 300 dpi. This is the sweet spot for ordinary body text. Below 200 dpi accuracy falls off quickly; above 400 dpi it does not measurably improve, while file size and processing time keep climbing. Very small print is the exception and benefits from 400–600 dpi.
• Contrast and evenness. Crisp black on white beats grey on cream. Photographs of documents suffer from uneven lighting and shadows across the page, which is why a phone snap OCRs worse than a flatbed scan of the same sheet.
• Straightness. Even a two-degree skew hurts if deskewing does not catch it. Flat on the glass, aligned with the edge.
• Compression artefacts. Aggressive JPEG on a scan smears character edges, and OCR reads edges. Scan for recognition first and compress afterwards, never the reverse.
• The right language setting, including for multilingual documents where many engines accept several languages at once.

Some errors are structural rather than fixable by settings. The classic confusions — rn read as m, 0 and O, 1 and l and I, 5 and S — come from genuinely similar shapes and are resolved by context, which means they persist exactly where context is absent: in serial numbers, IBANs, reference codes and passwords. Any workflow that OCRs identifiers should verify them against a checksum or a second source rather than trusting the output.

Handwriting is a different problem again — recognising cursive is a separate class of model from printed-text OCR, and general-purpose engines do it poorly.

Why OCR is rarely done in the browser

Most page-level PDF work — merging, splitting, rotating, deleting pages, signing, watermarking — is byte manipulation. It is fast, it needs no models, and a browser does it as well as a server.

OCR is not that. It needs trained models, which are tens to hundreds of megabytes per language, and it is compute-heavy per page. Both are possible in a browser — engines compiled to WebAssembly do exist — but the first page means downloading a model, and throughput is well below what a server delivers. That is why the free online tool that merges your PDF without asking anything may well upload it when you ask for OCR: the two operations have genuinely different requirements.

Which makes the practical order clear. Do the structural work locally, where local is free. If you need OCR, treat it as the one step where sending the file may be justified, and choose accordingly: for sensitive documents, an offline desktop engine; for ordinary ones, a provider whose retention policy you have actually read.

Working with a scan you cannot OCR

Plenty of tasks do not need a text layer at all, and it is worth knowing which, because reaching for OCR by reflex often adds a lossy step for nothing:

• Reorganising. Reordering, rotating, deleting, merging and splitting all operate on pages. They work identically on scans and never touch the image data.
• Signing. Adding a signature, a date or a note places new objects on top of the page. The page underneath being an image changes nothing.
• Stamping. Watermarks and page numbers are drawn over the image and work the same way.
• Extracting the pages as images. If what you need is the picture — for a slide, a report, an archive — exporting pages to JPG or PNG skips recognition entirely.

Where you genuinely need the text — searching, quoting, feeding another system — and the document is short, retyping the relevant passage is often faster than setting up OCR and then proofreading its output. Where the document is long, OCR is worth it, but budget time for verification: an engine that is 98% accurate still makes roughly one error per two lines of text.

Frequently asked questions

How do I know if a PDF has been OCR’d?

Press Ctrl+F and search for a word you can see on the page. A hit means there is a text layer. You can also try selecting a line: on an OCR’d scan the highlight appears over the words while the characters still look scanned.

Does OCR change how the document looks?

No. A searchable image PDF still displays the original scan; the recognised text is drawn in an invisible rendering mode underneath your selection. Some tools additionally clean or downsample the image, which does change appearance — that is a separate option, not OCR itself.

Can OCR be undone?

The text layer can be stripped, leaving the original image. But if the tool also re-encoded or downsampled the scan, that part is not reversible — keep the original file until you are satisfied with the result.

Why does my OCR output have the columns mixed together?

Layout analysis failed to detect the column structure and read across the page instead of down each column. Most engines have a layout or page-segmentation setting; forcing multi-column mode, or cropping each column and processing it separately, usually fixes it.

Is OCR accurate enough for legal or accounting documents?

For reading and searching, generally yes. For figures and identifiers, no — not without verification. The characters that OCR confuses most are exactly those in account numbers and amounts, and the language model that rescues ordinary words cannot help there.

Further reading

• What is actually inside a PDF file
• Why PDF files get so large
• Export PDF pages as images