OCR PDF

Your PDF never leaves your device, but the language model does come down from a public CDN the first time you use it. Recognition itself is local: pages are rendered inside the tab, and the Tesseract engine runs as WebAssembly in a web worker served from pdfchamp.app. The one piece that is not local is the training data. The first time you run OCR in a given language, roughly 10 to 15 MB of model data for that language is fetched from cdn.jsdelivr.net, after which your browser caches it and every later run in that language starts immediately. On a metered connection, budget for that one-off download per language. Fully offline, a language you have already used still works from cache, while a language you have never used cannot start, because its model has never been fetched.

Accuracy depends almost entirely on the page you feed it, and this tool will not quote you a number it cannot stand behind. Recognition is strong on clean, high-contrast printed text that sits straight on the page — a laser-printed contract, a typeset report, a crisp flatbed scan. It degrades on fax-quality output, photographs taken at an angle, faint carbon copies, heavily stylised display type, dense tables, text laid over background images, and pages skewed by more than a degree or two. Before you trust an output, use the preview pane: after a run it shows the recognised text for whichever page you are viewing, so you can page through and judge for yourself. When a page comes back wrong, the usual fixes are rescanning it straighter, raising the contrast, or correcting the language selection.

There is no automatic detection — recognition uses whichever language chip you select, and choosing wrongly is the most common cause of nonsense output. Twenty languages are available: English, Spanish, French, German, Italian, Portuguese, Dutch, Polish, Russian, simplified and traditional Chinese, Japanese, Korean, Arabic, Hindi, Turkish, Finnish, Swedish, Norwegian and Danish. Each has its own trained model with its own character set and word statistics, which is why an English model reads a Polish page badly rather than merely imperfectly. Switching the chip and running again reloads the engine with the new model, downloading it once if you have not used that language before. For a document that mixes languages, pick the one that dominates the body text; short foreign passages usually survive, and accented characters outside the selected model are the first thing to be misread.

In Searchable PDF mode, yes — the finished file keeps every page exactly as it looked and gains an invisible text layer positioned over the recognised words, so find-in-page, text selection and copy-paste all work. Pages that already carried a real text layer are copied through untouched rather than rasterised, so running OCR across a mixed document does not degrade the pages that were already fine. Pages combining a scan with a little native text — a letterhead, a stamp, a page number — keep their original content and get the recognised layer added on top of it. If a page could not be given a text layer, it still appears in the download unchanged and an amber notice tells you how many pages that happened to. The other mode, Plain text, skips the PDF entirely and writes a .txt file.

Around 300 DPI, in grayscale or bilevel, is the practical target for the scan you start from. Inside the tool every page is re-rendered at 150 DPI before recognition — a deliberate compromise between accuracy and the memory a browser tab can hold — and that render is what the engine sees. Scanning your original far above 300 DPI therefore buys little here, while scanning below roughly 200 DPI costs you: thin strokes merge, small type loses the shapes that distinguish it, and digits and punctuation are usually the first characters to be misread. Other properties of the source matter as much as resolution — even lighting, straight alignment, and genuine contrast between ink and paper. A well-lit 200 DPI scan usually beats a shadowed 600 DPI photograph of the same page by a wide margin.

Handwriting is not something this tool can do reliably. The engine is trained on printed and typeset characters, and the models offered here are the standard printed-text ones; there is no handwriting model in the list. Neat, well-separated block capitals — the kind you get on a form that asked for them — are sometimes recognised well enough to be useful. Ordinary cursive, hurried notes, signatures and margin annotations are not: expect either nonsense or nothing at all for those. If your document mixes a printed form with handwritten answers, running OCR still helps, because the printed part becomes searchable while the handwritten entries simply remain pixels in the page image. For documents that are handwritten throughout, a service built specifically for handwriting recognition is the right tool.