Making Scanned PDFs Searchable: How OCR Works and Which Scan Settings Matter

You scan a signed lease on the office copier, open the PDF, press Ctrl+F, type “deposit” — and nothing. The file looks like text, but what it holds is a photograph of text. To the computer it is a grid of light and dark pixels with no more meaning than a holiday snap. Optical character recognition (OCR) is how you get the words back.

Image PDFs, text PDFs and searchable PDFs

PDF pages come in three broad kinds:

Kind	Typically made by	Search and copy
Text PDF	“Save as PDF” from Word, Google Docs, LaTeX	Yes — characters are stored with their fonts
Image PDF	Scanners, phone scanning apps, “print to image”	No — each page is one picture
Searchable PDF	An image PDF with an OCR layer added	Yes — invisible text sits over the picture

The third kind relies on a small feature of the PDF specification: text rendering mode 3, which draws glyphs with neither fill nor stroke. OCR output is placed in that mode exactly over the words in the scan. You see the original image; your viewer uses the hidden words for search, selection, copy-paste and screen readers. If the blue selection highlight never quite lines up with the letters when you drag across a scanned page, this is why.

The design has a pleasant property: the visible page is never altered, so an OCR mistake cannot corrupt what you see — only what you search and copy. The flip side is that a sentence copied from a searchable PDF deserves a second look. What you copy is not necessarily what you see.

How an OCR engine reads a page

Modern OCR engines work in two stages.

Stage one: layout analysis. The engine finds regions that contain text and splits them into columns, paragraphs and lines, discarding pictures, table rules and specks along the way. Get this wrong on a two-column page and the output alternates between the left and right columns line by line.

Stage two: line recognition. Each cropped line image is turned into a character string. This is the part that has changed most.

Tesseract, the best-known open-source engine, was developed at Hewlett-Packard between 1985 and 1994, released as open source by HP in 2005, and developed under Google’s stewardship from 2006 until 2017. The engine described in Ray Smith’s 2007 overview paper first chopped each line into candidate characters and then classified each character by its outline features. That approach needs to know where one character ends before it can say what it is, which is why classic OCR confuses a touching “rn” with “m”, or reads “cl” as “d”.

Tesseract 4.0 made an LSTM (long short-term memory) neural network the default recogniser — in the documentation’s words, an engine “focused on line recognition”. It sweeps across the whole line image, carrying context forward, and emits the string in one go without committing to character boundaries first. That makes it far more tolerant of touching letters and ragged print. The price, per the same documentation, is roughly ten times the CPU of the old engine.

Deep-learning OCR systems such as PaddleOCR share the same skeleton. A detection network produces a map of how likely each pixel is to be text and turns it into line boxes; a recognition network reads each line. Recognition commonly uses CTC decoding: the line is treated as a sequence of narrow vertical slices, the network picks the most likely character (or “blank”) for each slice, and repeats are collapsed into the final string. The PDF OCR tool on this site offers both families — PaddleOCR models by default, and Tesseract (Korean and English) if you would rather not download a model.

Where the 300 DPI rule comes from

Tesseract’s documentation says it “works best on images which have a DPI of at least 300 dpi”. That number is not magic. It is a proxy for how many pixels each character gets.

A point is 1/72 inch, so the height of 10-point type is 10 × 300 ÷ 72 ≈ 42 pixels at 300 DPI, about 28 pixels at 200 DPI and about 21 at 150 DPI. For clean Latin text 21 pixels is often survivable, but the small marks are the first casualties: the dot over an i, the comma versus the full stop, the difference between 8 and B or 5 and S after a little ink spread. For Chinese, Japanese and Korean, where a single character may contain a dozen strokes in one square, the gaps between strokes drop to a pixel or two and similar characters start to swap.

A practical guide:

Ordinary body text (10–12 pt): 300 DPI
Footnotes, terms and conditions, receipts (8 pt and below): 400 DPI or more
Posters and large headings: 200 DPI is enough

One trap catches many people: you cannot add resolution after the fact. A PDF scanned at 150 DPI and rendered at 400 DPI for OCR just gets bigger pixels. The detail lost at scan time does not come back, so choose the resolution at the scanner.

Scanner settings that change the result

After resolution, four settings matter most.

Colour mode. A scanner’s “black and white” (1-bit) mode makes the smallest files, but the scanner applies a single threshold to the whole page. Faint pencil, light grey print and text near a shadowed spine can vanish at that moment, permanently. Scan in greyscale and you can apply adaptive thresholding later — methods such as Sauvola’s choose a threshold per pixel from the local brightness. Tesseract’s documentation notes that its built-in Otsu binarisation “can be suboptimal, particularly if the page background is of uneven darkness”.

Compression. Low JPEG quality leaves halos (ringing) around letter edges, and OCR happily reads those as strokes. Pick the scanner’s high-quality setting or a lighter compression level.

Skew. A few degrees of tilt are enough for the end of a long line to drift into the next one. The Tesseract documentation’s advice is simply to rotate the page until text lines are horizontal. Sheet feeders are the usual culprit. Straightening with the deskew mode of the scan enhancement tool before OCR makes recognition more stable, and because it only rotates the page’s coordinates instead of re-rendering, it costs no image quality.

Borders and shadows. Books scanned face-down pick up a dark gutter shadow and black bands at the edges; the Tesseract documentation warns that dark borders can be picked up as extra characters. Punch holes are read as “o” or full stops surprisingly often. Removing them before recognition is the reliable fix.

Phone captures add perspective distortion (the page becomes a trapezoid) and uneven lighting. Use your scanning app’s document mode so it squares the page, and shoot in even light without your own shadow across the paper.

Why CJK text is harder than English

English needs about a hundred symbols once you count upper and lower case, digits and punctuation. Unicode has 11,172 precomposed Korean syllables, and ordinary Korean text regularly uses a couple of thousand. Japan’s official list of kanji for general use has 2,136 characters before kana are added, and Chinese needs thousands more. More classes means more look-alike pairs, and each extra class needs training data.

Other difficulties compound this:

Near-identical characters. Pairs that differ by a single short stroke are common in all three scripts; at low resolution or with ink spread they are the first to fail.
Spacing. OCR infers spaces from gaps. Korean uses spaces between words, but syllable blocks are nearly equal in width and tight typesetting leaves little difference between an intra-word and inter-word gap. Japanese and Chinese use no spaces at all, so any the OCR inserts are wrong.
Mixed scripts. Korean legal text may include Chinese characters; Japanese business documents are full of English terms. A model trained for one script will miss the other, so choose the language setting to match the document.
Vertical writing. Tesseract 4’s documentation says vertical Chinese, Japanese and Korean text is supported and detected automatically, but not every OCR tool handles it. Check before you rely on it.

For Spanish, French or German the same logic applies at a smaller scale: an English-only model has to force é, ñ or ü onto the nearest plain letter. Always pick a model that knows your alphabet.

Why handwriting is still hard

Printed-text OCR rests on one assumption: the same letter in the same font looks almost the same every time. Handwriting breaks it. Letterforms vary from person to person and line to line, letters join, baselines wander and words spill out of form boxes. Reading handwriting needs a model trained specifically on it, and even then accuracy rarely matches print.

PaddleOCR says its PP-OCRv5 release improved recognition of Chinese and English handwriting. We found no comparable published claim for other scripts. In practice, when a form mixes print and handwriting, let OCR handle the printed parts and have a person transcribe the handwritten fields.

Checking whether you can trust the result

Engines report a confidence score per word. An average of 90% still means one word in ten may be doubtful, and that one could be an invoice total or an account number. A sensible check:

Start with the words flagged as low confidence and compare them with the scan.
Scan numbers, dates and names separately. Dictionary-based correction does not help there, so errors survive.
Search the finished PDF for a few key terms and make sure they are found.

Not every PDF needs OCR. Try PDF text extraction first. Empty output means an image PDF. Output that is present but garbled — random symbols instead of words — usually means the PDF has no correct ToUnicode map, the table that translates font glyphs back into characters. Extraction cannot fix that, and the pragmatic answer is, oddly, to OCR a PDF that technically already contains text.

A workflow that holds up

Scan at 300 DPI in greyscale, or 400 DPI for small print.
Fix orientation and skew; remove borders, shadows and specks.
Run OCR with the right language, then check low-confidence words and all numbers.
Confirm search works, and keep the original scan alongside the searchable copy.

That last step is worth the disk space. OCR keeps improving, and a good original scan can be read again by a better engine in a few years; a poor one cannot.