Open Tools Tools Features Blog About Contact Proof of Privacy

Extracting text from a scanned PDF

A scanned PDF has no text to extract — only pictures of pages. What OCR does instead, how accurate it is, and the measured time it takes.

HomeOCR › Extracting text from a scanned PDF

Where PDF came from, and why it is like this

There are two kinds of PDF that look identical on screen and are nothing alike underneath, and almost every frustration with PDFs traces back to not knowing which one you have.

A PDF exported from a word processor contains its text as text — characters, fonts, positions. You can select it, search it, and copy it, and pulling that text out is instant and perfect.

A scanned PDF contains photographs of paper. Every page is one large image, and there is no text anywhere in the file. Selecting does nothing because there is nothing to select. This is what comes out of every office scanner, every phone document-scanning app, and every archive digitised before about 2010 — and it is why converting it to a Word document returns an empty file. That conversion is not broken; there was genuinely nothing there.

Optical character recognition is the only way across that gap. It looks at the pixels and works out what the letters were.

Is this conversion lossy?

The question is really about accuracy, because nothing is being converted — text is being reconstructed from an image of text, and reconstruction is guesswork with a good success rate rather than a lookup.

Clean scans of printed documents at a decent resolution come out very well. What degrades it: low-resolution scans, pages photographed at an angle or with a curved spine, faint or photocopied originals, unusual typefaces, coloured or watermarked backgrounds, and dense tables. Handwriting is not recognised by this engine at all.

The failure mode is what matters. OCR rarely announces that it is unsure — it returns confident text with occasional wrong characters, and a misread digit in a reference number or an amount looks exactly like a correct one. Anything consequential has to be read against the original page.

It is also slow in a way the other conversions on this site are not. Recognition is real computation on every pixel of every page, and page count drives the time almost linearly. The measured figure below is for a ten-page document; a two-hundred-page scan is a different proposition entirely.

What happens to metadata, transparency and colour

Layout does not survive. The output is a plain stream of characters. Columns, tables, headers, footnotes and captions are read in whatever order the engine works through the page, so multi-column documents frequently interleave.

Nothing else survives either — no formatting, no images, no page structure. Plain text cannot hold them.

The original PDF is unchanged. This produces a separate text file rather than adding a searchable text layer back into the PDF. If what you want is a scanned PDF that has become searchable in place, that is a different operation and this is not it.

Resolution is the thing to fix if accuracy is poor. Recognition wants roughly 300 dots per inch. A scan made at 150 dpi to keep the file small is the most common cause of bad output, and re-scanning at a higher setting helps far more than any amount of retrying.

Why people actually need this

Something in a scanned document needs to be found, quoted or reused, and it cannot be. Searching a long scanned contract for one clause. Pulling figures out of a scanned invoice. Quoting a paragraph from a scanned article without retyping it. Checking whether a particular name appears anywhere in two hundred pages of scanned minutes.

The other common case is accessibility and compliance: a scanned document is completely opaque to a screen reader, so extracting the text is the first step to making its contents available to someone who cannot see the page.

What we measured

This conversion was run end to end before this page was written. Not "should work" — run, with the output checked:

Verification runResult
Source file usedpdf-pages-10.pdf (35 KB)
Output produced30 KB
Output type reported by the browsertext/plain;charset=utf-8
Time to produce it1 min 6 s

And the ceilings measured for OCR, the tool that performs it, on the hardware described on the limits page:

Not tested

The page also refuses files above 100 MB before it starts, which is a guard written into the tool rather than something the browser imposes. Why those are different.

When something else is the better answer

Check first whether the PDF is actually scanned. Extracting its text directly takes a second, and if it returns anything, the file has a real text layer and that result will be perfect where OCR would only be good. It is worth doing every time before reaching for recognition.

If the document is mostly tables of figures, plain text will run the columns together. Reading it as a spreadsheet keeps the structure that makes the numbers mean anything.

If the scan is long, check the page-count row for the OCR tool on the measured limits page before starting. This is the slowest operation on the site by a wide margin, and it runs in your browser tab.

If the original digital file exists anywhere — the document before it was printed and scanned — use that. Every OCR result is a reconstruction, and the original is not.

Do it now: OCR runs entirely in your browser — nothing is uploaded.

Related: Converting PDF to an editable document · Extracting text from an image