Make a scanned PDF searchable with OCR

How to OCR — Searchable PDF

1. Add your scanned PDF. Drop the file in. The tool checks each page and tells you how many have no text layer — those are the scans it will read.
2. Pick a quality level. 300 DPI suits ordinary print. Raise it for small type, lower it if you would rather have the result sooner.
3. Make it searchable. Each page is rendered and recognised in turn. The first run downloads the recognition model once, about 6MB, and caches it.
4. Download. You get the original document back with an invisible text layer added. Try selecting a line — the words are now there.

What actually gets added to your file

The scan is not modified, re-encoded or rebuilt. Each page keeps its own content exactly as it was and gains a second content stream holding the recognised words, drawn in what the PDF specification calls text rendering mode 3 — neither filled nor stroked. The glyphs are genuinely present for search, selection and assistive technology, and genuinely invisible on screen.

That is why the output looks pixel-identical to what you put in, and why bookmarks, annotations and form fields survive. A tool that rebuilds pages from images to add text would lose all of that and re-compress your scan on the way through.

Each word is also horizontally scaled to match the width of the ink underneath it, so when you drag to select a line the highlight lands on the words rather than drifting away from them.

Pages that already have text are left alone

Running recognition over a page that already carries a text layer leaves two copies of every word in the file. Copy a paragraph out and you get it twice. Search matches it twice. It is a common and quietly annoying failure of batch OCR.

So pages are checked first, and any that already have extractable text are skipped by default. The result tells you how many were skipped rather than silently doing nothing, and you can turn the behaviour off for the rare case where an existing text layer is wrong and you want it re-read.

Getting a good result

Almost all of the accuracy is decided before recognition starts, by the quality of the scan rather than by the settings here.

• 300 DPI is the practical floor for ordinary print. Below roughly 200 the glyph shapes stop being distinguishable and accuracy falls away quickly.
• Straight pages beat clever software. A page scanned at an angle costs more accuracy than any setting recovers.
• Even lighting matters more than resolution. A shadow across the page — usually your own head, if you photographed it — makes the contrast adjustment overcorrect everywhere else.
• Greyscale is fine, and often better than colour for plain printed text.
• Handwriting will not work. Recognising handwriting is a different problem from recognising print, and this engine is trained on print.

What it will get wrong

Worth knowing the failure modes, because they are predictable rather than random. Recognition leans on a language model to resolve ambiguous shapes, which is why ordinary prose comes out far more accurate than isolated strings.

Serial numbers, licence keys and account numbers lose that help entirely, so the confusable pairs stay confused: 0 and O, 1 and l, 5 and S, 8 and B. Tables are recognised character by character perfectly well and then lose which cell each value belonged to. And a page at 98% character accuracy still holds roughly one error every two lines.

Proofread anything that matters. OCR makes a document searchable; it does not make it verified.

Why this runs in your browser

Scanned documents are disproportionately the sensitive ones — contracts, medical letters, bank statements, identity documents. They are exactly the files people are least comfortable uploading to a stranger's server, and exactly the files most OCR services require you to upload.

Here the recognition engine is WebAssembly running in a worker in this tab, and the language model is served from this site rather than a content delivery network. Nothing about the document, or the fact that you ran OCR on it, reaches anyone. Once the model is cached the tool keeps working with the network switched off, which is a simple way to confirm the claim for yourself.

English only, and why that is stated rather than fudged

The recognition engine supports over a hundred languages, but the text layer written into the PDF uses a standard font whose encoding covers Latin scripts. Producing a correct layer for Greek, Cyrillic, Arabic or CJK means embedding a Unicode font into every file the tool outputs, which would add megabytes to each one.

Rather than offer languages that would produce a subtly corrupted text layer, the tool does English and says so. That is a real limitation and it is better read here than discovered in the output.

Frequently asked questions