You can search a forty-page digital PDF in a second because the words are in the file as text. A scanned PDF has none of that — it's photographs of pages — which is why Ctrl+F finds nothing and copy-paste gives you a screenshot. OCR (optical character recognition) is the bridge: it looks at the pixels and works out the words. Here's when you actually need it, what it can and can't read, and how to run the whole thing without handing a confidential scan to an upload-and-pray website.
The one-second test: try to highlight a sentence. If the words light up as you drag, the file has a text layer — copy away, search away, done; OCR would only re-type what's already there, with typos. If instead your cursor draws an empty blue rectangle, you're looking at an image of text, and that's the OCR case. Scans, photos of pages, faxes received as PDF, and anything exported "as image" all land in this bucket.
It's worth the test, because running OCR on a digital PDF is pure downside: slower than copying and strictly less accurate than the original text.
The engine renders the page into high-resolution pixels, carves them into zones, lines, words, and characters, then matches each candidate glyph against a trained language model that also knows context — English words, common layouts, how a "rn" differs from an "m". The output is plain text (plus, in fancier pipelines, coordinates for making searchable PDFs). Two open-source pieces do this well in a browser: pdf.js turns the PDF into images, and Tesseract — originally built at HP, maintained as open source for decades — reads them.
Because resolution is the accuracy dial, and 300 DPI is where small print becomes reliably readable pixels. The arithmetic: PDF pages measure in points (72 per inch), so rendering multiplies by DPI ÷ 72. A US Letter page, 612 × 792 points, becomes:
| DPI | Letter page becomes | Relative pixels | Good for |
|---|---|---|---|
| 72 | 612 × 792 px | 1× | Screen viewing — too coarse for OCR |
| 150 | 1275 × 1650 px | ~4× | Headlines, forms, large type |
| 300 | 2550 × 3300 px | ~17× | Body text, contracts, receipts |
Halving the DPI quarters the pixel count — that's why 150 DPI runs roughly four times faster than 300, and also why its mistakes multiply on eight-point footnotes. If the source scan was captured at low resolution, re-rendering higher can't invent detail the scanner never recorded; fix it at the scanner.
The practical review rule: proofread the things that matter and are hard — numbers, names, dates, amounts. Engines rarely miss "the", often slip on "l/1" and "O/0".
The engine arrives on demand. First press of the button fetches Tesseract's JavaScript plus its WebAssembly core (about 4.5 MB) and a language model (roughly 10 MB for standard English, about 2 MB for a fast variant) from a public CDN. Everything is cached, so subsequent pages and future visits start instantly. Your document does the opposite of traveling: it's read from disk into the tab, rendered by pdf.js, and processed by the WebAssembly engine locally. For confidential scans — medical records, legal files, financial statements — that's the difference between OCR and a data leak with extra steps.
Our OCR PDF tool runs the pipeline described above entirely in your browser: open the scan, choose language and DPI, toggle off pages you don't need, and copy or download the transcript. It's deliberately a text-out tool — for images you want PDF to JPG, and if the file is digital-with-text you wanted page extraction, not OCR, all along.
Render at 300 DPI, recognize with Tesseract, copy the text — all local, all free.
OCR PDF →Highlight first: if text selects, you don't need OCR. If it doesn't, feed the scan as many clean pixels as you can — 300 DPI when in doubt — and proofread the numbers. Run it in a browser when the document is private, because a local engine reads your scan without anyone else ever seeing it.