PDF OCR Text Layer

About PDF OCR Text Layer

The tool ships two recognition engines. The default, AI recognition, runs PaddleOCR models — PP-OCRv3 for finding text lines and PP-OCRv5 mobile for reading them — through ONNX Runtime in your browser. Basic recognition uses Tesseract's LSTM engine (tesseract.js) with the Korean and English best_int language data. Both are downloaded from this site and run locally, so the scan is never uploaded to an OCR service.

The output is not a re-drawn copy of your PDF. The page content is left byte-for-byte alone; each recognised word is added on top at its original position using PDF text rendering mode 3, the mode that neither fills nor strokes glyphs. You still see the scan, but the viewer uses that hidden layer for search, selection, copy and screen readers.

The two engines read a page differently

Tesseract first analyses the layout of the whole page — blocks, paragraphs, text lines — and then feeds each line to an LSTM network that outputs a character string. Since version 4.0 that neural line recogniser has been the default; the older character-classifier engine is what it replaced. Tesseract expects a binarised page, so before handing a page to it this tool flattens the background, applies Sauvola adaptive thresholding and removes specks. It also passes the render resolution as user_defined_dpi so the engine does not have to guess the text size.

The PaddleOCR path starts with a DB (Differentiable Binarization) detector that produces a map of how likely each pixel is to be text. Line boxes are pulled from that map, each line is cropped and scaled to 48 pixels tall, and the recogniser emits the whole string at once using CTC decoding — it never has to decide where one character ends and the next begins. Neural recognisers read soft edges better than hard black-and-white ones, so with clean-up switched on this path gets a flattened, denoised greyscale image rather than a thresholded one.

The AI detector looks at the page scaled to 1600 pixels on the long side. Raising the DPI therefore barely changes where lines are found; what it improves is the sharpness of each cropped line, which is where accuracy is decided.

Why 300 DPI is the default

Tesseract's own documentation says it works best on images of at least 300 DPI. What really matters is how many pixels one character gets. At 200 DPI a 10-point line of text is about 28 pixels tall; that is plenty for English capitals but tight for Korean, where a syllable block stacks up to three or four components in the same square, and for dense kanji. Gaps between strokes shrink to one or two pixels and look-alike characters start to swap.

The tool offers 200, 300 and 400 DPI and starts at 300. Use 400 for footnotes, receipts and anything set below 8 points. Keep in mind that the setting only controls how the PDF page is rendered for recognition: if the scan inside the PDF was captured at 150 DPI, rendering it at 400 enlarges pixels without adding detail. When moving from 300 to 400 changes nothing, you have hit the limit of the original scan. Rendering also stops at 7000 pixels on the long side, so very large drawing sheets are read below the chosen DPI.

Choosing a language chooses a model

AI recognition downloads one recognition model per script family, once. Korean (about 12.8 MB) also reads English and digits. Spanish uses a shared Latin-script model (about 7.7 MB) that also covers French, German, Portuguese and similar languages, including accented letters such as ñ and ç. Japanese uses a CJK model (about 15.8 MB) that also reads Chinese characters and English.

Basic recognition only contains Korean and English data and will not run for Spanish or Japanese. A mostly-English document with a few accented names is still better served by the Spanish (Latin) model in AI mode than by the English Tesseract data, which has to force é or ü onto the nearest plain letter.

How the tool decides a page already has text

“Skip pages that already have enough text” does not skip every page with any text at all. Scanners often stamp a filename or page number into the file, and a rule that simple would leave whole scanned pages unrecognised. A page counts as covered only when it has at least 80 characters and those characters' boxes cover at least 1% of the page.

Even then the tool double-checks. It renders the page at about 100 DPI and looks for character-shaped ink outside the existing text boxes — a screenshot pasted into a Word document, for example. If there is a lot of it, the page is recognised anyway. When a page already carries a hidden OCR layer from an earlier run, that layer is removed and replaced, so a search does not hit every word twice.

Documents that still go wrong

Handwriting: both engines are trained mainly on print, and cursive notes on a form will produce little that is usable. Stamps over text, heavy highlighter, and certificates with guilloche background patterns also lower accuracy. Vertical Japanese (tategaki) is effectively not read in the AI path at present, because tall narrow boxes are discarded as table rules.

Skewed scans are worth straightening first with the enhance-scan tool's deskew mode. Line detection works with horizontal boxes, and a tilt of three or four degrees is enough for long lines to pick up pieces of the lines above and below.

Worked examples

How to use it

1. Add a scanned PDF; pages that already carry text are reported first.
2. Pick the engine, document language, resolution (300 DPI by default) and page range.
3. Run it and review the word boxes and mean confidence in the preview.
4. Download the searchable PDF and the .txt, then test a search in your viewer.

Frequently asked questions

Related guides

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