OCR a Scanned PDF

First, work out whether you need OCR at all

A PDF can hold text in two completely different ways, and they look identical on screen.

A digital PDF — anything exported from Word, a browser, LaTeX or a design tool — stores the characters themselves. Open it and try to select a sentence: if the cursor highlights words, the text is already there. You do not need OCR, and running it would be a waste of several minutes. Copy the text, or use a PDF-to-text tool.

A scanned PDF stores a photograph of a page. Selecting a sentence highlights nothing, or highlights a rectangle covering the whole page image. Searching finds nothing. This is what OCR is for: reading the shapes in the picture and working out which characters they are.

Mixed documents exist and are common — a digital contract with a scanned signature page appended, for example. Running OCR over the whole thing is harmless but slow; the page range field lets you do just the scanned pages.

Scan quality decides most of the outcome

Optical character recognition is pattern matching over pixels. Nothing downstream can recover detail the scan never captured, so the quality of the source dominates everything else you can control.

Resolution. The useful figure is not the DPI of the file but the height of a lowercase letter in pixels. Below roughly 20 pixels, recognition degrades badly; around 30 to 40 pixels it is comfortable. Ordinary 10-point body type reaches that at about 200–300 DPI. A 600 DPI scan of the same page is four times the data for no gain in accuracy.

Straightness. A page fed crookedly through a scanner, or photographed at an angle, is much harder than a square one. Tesseract tolerates a degree or two and struggles beyond that. This tool does not deskew: automatic straightening needs an angle estimate, and a wrong estimate makes things worse silently, which is a poor trade for a tool you cannot inspect. If your pages are visibly crooked, re-scanning them straight is worth more than any setting.

Contrast and evenness. Grey text on a grey background, a phone flash blowing out the middle of a glossy page, a shadow from the photographer's own head — each of these removes whole lines. A flatbed scanner or a document-scanning phone app beats a casual photograph by a wide margin.

Compression. A scan already saved as a small JPEG carries ringing artefacts around every letter. They are invisible at a glance and very visible to a character classifier.

Layout. Plain single-column body text is the easy case. Dense tables, multi-column layouts with narrow gutters, text printed over photographs, and stylised display faces are all considerably harder. Handwriting does not work at all — Tesseract's models are trained on printed type, and cursive produces confident nonsense.

Why the tool renders every page at 200 DPI

Before recognition each page has to become pixels, so the tool rasterises it with pdf.js. The scale it uses is 200 DPI, and both directions from there are worse.

Lower, and letters fall under the pixel height the models need. Higher, and you are enlarging a photograph: if the embedded scan is 200 DPI, rendering the page at 400 invents no new detail, it just quadruples the work. Since a scanned PDF is usually 200–300 DPI to begin with, 200 is where accuracy stops improving and cost keeps rising.

Two adjustments happen automatically. Pages are converted to grayscale, which roughly halves recognition time and loses nothing — Tesseract discards colour internally regardless. And a page big enough to exceed what browsers will allocate for a canvas (an A0 plan at 200 DPI would be about 119 megapixels) is rendered at a reduced scale instead of failing; the word positions are mapped back through the image's real size, so the searchable layer stays correct.

Why the language models here are the "fast" ones

Tesseract publishes its trained models in three sets. tessdata_best is the most accurate and the largest. tessdata is the middle. tessdata_fast is integer-quantised for speed and size.

This site ships fast, and the reason is arithmetic rather than preference. English in fast is about 4 MB; in best it is roughly four times that. Every visitor who presses the button downloads it. The accuracy difference is real but small — on the order of two to three per cent of characters, concentrated in the hard scans where the output needs correcting either way. Paying 15 MB per visitor for that on every language would be the wrong default, so it is not the default. It is also a genuine ceiling on what this tool can do, which is why it is written down here rather than left for you to discover.

Four languages are available — English, Vietnamese, Spanish and Portuguese — because those four model files are shipped with the site. Tesseract supports over a hundred, but each additional one would have to be fetched from a third-party CDN at the moment you selected it, which would leak the fact that you are reading a document in that language. That is the request this tool exists to avoid, so the list stops at what can be served from here.

What "searchable PDF" actually means

This is the option most people are looking for, and the name is doing a lot of work.

The tool loads your original file with pdf-lib and, for every word the recogniser located, draws that word at zero opacity in the place on the page where the ink is. The scan underneath is untouched: not re-rendered, not re-compressed, not converted. What you get back looks pixel-for-pixel like what you put in, but Ctrl+F finds words, text selection works, and anything that indexes PDFs — Spotlight, Windows Search, a document management system — can read it.

Three details are worth knowing:

• Position comes from the recogniser, not from guesswork. Each word's box is in pixels of the rendered image, origin top-left; PDF coordinates are points, origin bottom-left; and a page may carry a /Rotate flag that the reader applies but the drawing layer does not. All three conversions happen per page, using the rendered image's actual width rather than an assumed DPI.
• Low-confidence words are left out. Below 30% confidence, output is usually speckles read as punctuation, and including it makes selecting a line copy junk between the real words.
• The layer is only as good as the OCR. A word read wrongly is searchable under the wrong spelling. Invisible text hides its own mistakes, which is a reason to check the .txt output on a page or two before trusting a large batch.

For English, Spanish and Portuguese the invisible text uses Helvetica, one of the fonts every PDF reader already has, so the file grows by tens of kilobytes. Vietnamese needs an embedded Unicode font — Helvetica's character set cannot spell it — so a 421 KB Noto Sans file is fetched from this site and subset down to just the glyphs used.

What the first run downloads, and where it goes

Opening the page downloads no OCR machinery at all. Press Recognize text and three things arrive, all from this origin:

The language file is written to your browser's IndexedDB by tesseract.js, which is why the second document in the same language starts recognising immediately. It is your own storage; clearing site data removes it and the next run fetches it again. Nothing is sent anywhere — the only network traffic is these downloads from the site you are already on.

A working order of operations

1. Try selecting text in your PDF first. If it selects, you do not need this tool.
2. Pick the language of the document, not your own language.
3. Run one page — put 1 in the page range — and read the output. Thirty seconds here tells you whether the scan is good enough before you spend ten minutes on 200 pages.
4. If confidence is under about 70%, fix the input rather than the settings: re-scan straighter, at 300 DPI, in grayscale.
5. Decide what you actually want. .txt if the text is going to be edited or re-used; searchable PDF if the document has to stay a document and just needs to be findable.
6. For long jobs, use the page range to work in batches. Stop abandons the run if you change your mind — it does not hand back the pages read so far, which is exactly why batches are worth the trouble.

Is my document uploaded anywhere?

No. Each page is rendered to a canvas by pdf.js, recognised by Tesseract compiled to WebAssembly, and — if you ask for a searchable PDF — reassembled by pdf-lib. All three run inside this browser tab. Nothing about the document reaches a server, so there is no stored copy to retain, log or delete.

This is the whole reason the tool exists in this form. Every other free "OCR PDF" service posts your file to a machine you do not control, and scanned PDFs are overwhelmingly the documents you would least want to hand over: contracts, medical records, bank statements, land titles, court filings. You can verify it: open the Network tab, run the tool, and after the language file loads you will see no request carrying the PDF.

What is a "searchable PDF" and what does the option actually change?

It is the same scan, visually unchanged, with the recognised words written over the image in invisible text. Your reader can then find, select and copy words that only exist in the document as pixels.

Nothing is redrawn or re-compressed. The tool loads your original file, and for each word Tesseract found it draws that word at zero opacity, positioned over the place on the page where the ink is. The scan you see afterwards is byte-identical in appearance; only a text layer has been added. That means the file grows by a few tens of kilobytes rather than being re-encoded — and it also means the quality of the image is exactly what you started with, for better or worse.

If you leave the option off you get plain .txt with a --- Page n --- marker before each page, which is the better output when you intend to edit or re-use the text rather than keep the scan.

Why does it take so long, and can I stop it?

Recognition is genuinely expensive: roughly one to five seconds per page on a modern laptop, more on a phone, plus a one-off start-up cost the first time. A fifty-page scan is a few minutes of real work, and it is your own CPU doing it — a server-side service feels faster because the work happens on somebody else's machine.

There is a Stop button. It ends the run: the page being read is abandoned, the recognition engine is shut down, and the loop does not move on to the next page. What it does not do is hand you the pages it had already finished — a stopped run produces no text at all, and the button stays in its "stopping" state until the run has actually unwound, which is normally a fraction of a second.

So if you only want part of a document, use the page range field rather than Stop: reading pages 12–14 of a 200-page scan takes seconds and gives you those three pages.

What gets downloaded the first time?

Nothing until you press Recognize text. Then, from this site and never from a CDN: the worker script (~110 KB), the WebAssembly engine (~3.8 MB), and the language data (0.5–4 MB depending on the language). The language file is cached in your browser's IndexedDB, so the second document in the same language downloads nothing. Choosing the searchable-PDF option in Vietnamese additionally fetches a 421 KB Noto Sans file, because the built-in PDF fonts cannot spell Vietnamese; the other three languages use a font every PDF reader already has.

Why 200 DPI, and does resolution matter?

Each page is rendered at 200 dots per inch before recognition. Tesseract's models were trained on material around 300 DPI for ordinary body type, and below about 150 DPI accuracy falls away quickly. Rendering above the resolution of the original scan adds pixels but no information, so it only makes recognition slower — 200 is where the curve flattens for the documents this tool sees.

What does matter is the scan you started with. A 150 DPI grayscale scan of a clean printed page will do very well. A photograph of a page taken at an angle, a fax, or a scan someone has already compressed to a small JPEG will do noticeably worse, and no setting here can recover information the scan did not capture. Pages are converted to grayscale before recognition, which is roughly twice as fast and no less accurate, since Tesseract discards colour internally anyway.

Why do some words go missing from the searchable layer?

Two reasons, both reported rather than hidden. Words the recogniser was less than 30% confident about are left out on purpose: at that level they are usually speckles read as punctuation, and including them makes selecting a line copy junk.

The other reason is the font. For English, Spanish and Portuguese the invisible layer is drawn in Helvetica, whose character set is roughly Latin-1. Vietnamese uses an embedded Noto Sans instead, which covers about three thousand code points — the Latin alphabet with every Vietnamese tone mark, Greek, Cyrillic and common punctuation. Either way, a word containing a character the font has no glyph for is left out and counted, and the count appears above the text. Characters that fall outside both are rare in practice and usually mis-reads to begin with: CJK, arrows and box-drawing lines that OCR extracted from a stamp or a table border. The .txt output has no such limit — it contains every word regardless of font.

What if the searchable PDF cannot be built?

You still get the text. The tool checks your original before it starts reading — a file with permissions or a password on it can be displayed but cannot have a text layer written into it, and that is refused up front rather than after several minutes of recognition. If something goes wrong later, at the assembly step, the recognised text and the .txt download stay on the page and a message explains why the PDF is missing.

A password-protected original is the common case. Remove the protection first, or turn the searchable-PDF option off and take the text on its own.

How accurate is it?

The language files are Tesseract's tessdata_fast models — quantised for speed and size. On a clean printed page expect the high nineties per cent of characters; the tool reports an average confidence per page so you can see which pages are weak. tessdata_best would be about two to three per cent better and four times the download, which is not a trade worth making for every visitor. Handwriting does not work at all, and dense tables, multi-column layouts with narrow gutters, and text printed over images are all substantially worse than plain body text.