An OCR step turns a picture of a page back into text. That is the whole idea, and it is the difference between a PDF you can search and a PDF that is just a photograph pretending to be a document. If you have ever opened a scanned invoice, tried to select a number, and watched your cursor drag a blue box across nothing, you have met an image-only PDF.
This guide covers how to OCR a PDF in Adobe Acrobat, how to do it free with open-source tools, what Google Drive will and will not do, and the DPI threshold below which OCR quietly stops working. It also covers the part most guides skip: once you have OCR'd the file, you still do not have a spreadsheet, and there is a specific reason why.
How do I OCR a PDF?
Open the PDF in a tool that has an OCR engine, run text recognition on it, and save. In Adobe Acrobat, go to All Tools, then Scan and OCR, then Recognize Text, and choose In This File. Acrobat usually detects a scanned page on open and offers a Recognize Text prompt at the top of the window. The page image stays exactly as it was. What changes is that an invisible text layer is added underneath it, so the characters become selectable and searchable.
That text layer is the entire product of OCR. Nothing about the visible page moves. This matters later, because a text layer is not the same thing as a table, and no amount of OCR will make it one.
How do I make a PDF searchable?
Making a PDF searchable and running OCR on it are the same operation described from two ends. OCR is the process, a searchable PDF is the result. Run text recognition in Acrobat, or run ocrmypdf input.pdf output.pdf from a terminal, and the file that comes out has an invisible text layer you can search with Ctrl+F, select, and copy.
One quirk trips people up here. Acrobat refuses to OCR a page that already contains renderable text, and returns an error saying it could not perform recognition. That is not a failure, it is a guard: the page already has real text, so there is nothing to recognize. The same is true of ocrmypdf, which skips pages that already carry text unless you pass --force-ocr or --redo-ocr.
Can Adobe Reader OCR a PDF?
No. The free Adobe Acrobat Reader on the desktop views, prints, and comments on PDFs, but text recognition is not part of it. OCR ships in the paid desktop apps, Acrobat Standard and Acrobat Pro. Adobe does run a separate free OCR tool on the web that will make a PDF searchable at no cost, though editing the recognized text still pushes you toward a Pro trial or a subscription.
This is the most common misunderstanding about Adobe and scanned documents, and it is close cousin to the other one: the free Reader cannot export a PDF to Excel either.
How do I OCR a PDF for free?
Use ocrmypdf, which wraps the open-source Tesseract engine and rebuilds a proper searchable PDF around it. The minimal command is:
ocrmypdf input.pdf output.pdfSpecify a language for better accuracy, since Tesseract does noticeably better when it is not guessing:
ocrmypdf -l eng input.pdf output.pdfIt is genuinely good software, and it is free. Its limits are Tesseract's limits, and they are documented rather than mysterious. Tesseract cannot read handwriting at all. It can produce gibberish and hand it back as though it were text, with no signal that anything went wrong. It struggles with multi-column layouts and will happily read across a column boundary, joining two unrelated sentences. And it returns text plus bounding boxes, nothing more: no paragraphs, no headings, no font information.
Does Google Drive OCR a PDF?
Yes, and it is the fastest free option for a single page. Upload the PDF to Drive, right-click it, choose Open with, then Google Docs. Drive runs OCR and produces a document with the original image at the top and the extracted text below it.
Google publishes real constraints on this, and they are tighter than people expect. The file should be 2 MB or smaller. Text needs to be at least 10 pixels tall. The document must be right-side up, so rotate it before uploading rather than after. Over 100 languages are detected automatically.
The constraint that matters most for anyone working with financial documents is buried in Google's own help page: lists, tables, columns, footnotes, and endnotes are not likely to be detected. Bold, italics, font size, and line breaks usually survive. Your table does not. Drive will hand back the words in your table as ordinary paragraph text, in roughly reading order, with the column structure gone.
Which OCR tool should I use?
| Tool | Cost | Reads a scan | Gives a searchable PDF | Gives a spreadsheet |
|---|---|---|---|---|
| Acrobat Standard or Pro | Paid subscription | Yes | Yes | Only via a separate Export to Excel step |
| Adobe Reader (free desktop) | Free | No | No | No |
| ocrmypdf plus Tesseract | Free, open source | Yes | Yes | No |
| Google Docs, opened from Drive | Free | Yes | No, it makes a Doc | No, tables are not detected |
| OneNote, Copy Text from Picture | Included with Office | Yes | No, text to clipboard | No |
| A PDF to Excel converter | First file free | Yes | No | Yes, rows and columns |
OneNote is the quiet one on that list. Right-click an inserted image or scan and choose Copy Text from Picture, and it OCRs to the clipboard. It works in OneNote on Windows, Mac, iOS and Android, but not in OneNote on the web. On a Mac, Live Text in macOS Monterey and later will let you select text out of images in Preview, though extraction from scanned PDFs specifically is inconsistent enough that I would not build a workflow on it.
What DPI should I scan at for OCR?
At least 300 DPI. Tesseract's own documentation says it works best on images of 300 DPI or higher, that accuracy drops off below 10pt text at 300 DPI and falls away rapidly below 8pt, and that recognition is best when capital letters are 20 to 40 pixels tall. Adobe gives the same practical advice for its own OCR.
Below roughly 200 DPI, treat the output as unreliable regardless of which engine you use. Above 600 DPI you gain nothing except a much larger file. If you are scanning small print, going to 400 or 600 is reasonable. Going to 1200 is just slower.
| Scan resolution | What to expect |
|---|---|
| Under 200 DPI | Unreliable. Expect substitution errors in numbers. |
| 300 DPI | The documented minimum for good results. Use this by default. |
| 400 to 600 DPI | Worth it for small print. No accuracy penalty, larger files. |
| Above 600 DPI | No measurable accuracy gain. Bigger, slower files. |
Why is my OCR text wrong?
Five things ruin OCR accuracy, and four of them happen before the file reaches the software. Low resolution is the first, as above. Skew is the second: a page scanned at an angle, or photographed from a phone held slightly off square, degrades badly, and the fix is to de-skew before recognition rather than to blame the engine. Low or uneven contrast is the third. Handwriting is the fourth, and it is not a matter of degree: Tesseract cannot read it.
The fifth is the layout itself. Borderless tables, where columns are separated by whitespace rather than ruling lines, are hard for every engine, because the only evidence a column exists is that the characters happen to line up.
When OCR does misfire on clean print, it usually misfires the same way, substituting characters that look alike. Zero and capital O. The digit 1, lowercase l, and capital I. The digit 5 and capital S. The digit 8 and capital B. In a document full of prose this is a nuisance you would probably catch by reading. In a document full of account numbers and dollar amounts, it is a silent error that survives every visual check, which is why you should verify a conversion against the source before you rely on the numbers.
Is a searchable PDF the same as a spreadsheet?
No, and this is the step that surprises almost everyone. OCR gives you a text layer. A text layer is a stream of characters, each with a bounding box saying where on the page it sits. That is all Tesseract promises to return, in its own documentation: the text and its bounding box. There is no row. There is no column. There is no cell. There is no header.
So you can search the OCR'd PDF for an invoice number and find it, and you can select a paragraph and copy it, and you still cannot get the table into Excel, because nothing in the file knows it is a table. Copying it out drops everything into a single column, or scatters one row across three. Reconstructing the grid takes a second and entirely separate operation, called table extraction, which looks at the alignment of those bounding boxes and works out where the columns and rows must have been, including in borderless tables where it has to infer boundaries from alignment alone.
OCR makes a PDF searchable. Table extraction makes it a spreadsheet. They are two different jobs, and most free tools only do the first one. A converter that runs OCR and then table extraction does both in one pass, which is why a scanned bank statement can go in and a clean XLSX with numbers that actually sum can come out. If you want the mechanics of that second step on its own, the guide to extracting tables from a PDF covers it, and the broader walkthrough of how to convert a PDF to Excel compares every route.
Putting it together for a scanned document
If your goal is a searchable archive, OCR is the finish line. Run ocrmypdf across the folder, keep the originals, and move on. If your goal is data you can total, sort, or reconcile, OCR is step one of two, and running it by itself will leave you retyping the numbers by hand into the sheet you needed all along.
For that second case, skip straight to a tool that does both: upload the scan to the scanned PDF to Excel converter and take back an XLSX, or a CSV if it is heading into another system rather than in front of a person. Then do the thirty-second check that catches OCR damage: count the rows against the source, total one numeric column against the printed total, and scan the ID column for the character substitutions above.
At small volumes this is a per-file task and any of the tools here will serve. Once a team is processing hundreds of scanned documents a month, and the cost of a single transposed digit is a restated report rather than an annoyance, the workflow moves to automated extraction that no person touches, with validation rules that catch the substitution errors before the data lands anywhere. That is a different scale of problem than making one PDF searchable, but it starts with exactly the same distinction: recognizing characters and understanding a table are not the same thing.