How to make a PDF searchable with OCR, free

What OCR actually does to a PDF

A PDF page is either text-based (every glyph stored as a character in a font) or image-based (the page is just a picture). Text-based PDFs are inherently searchable — the text layer is part of the file structure per the ISO 32000-1 specification. Image-based PDFs are not — there are no characters in the file, only pixels arranged to look like characters.¹

OCR (Optical Character Recognition) bridges the gap. The OCR engine reads the pixels, identifies clusters that look like glyphs, decides which character each cluster represents using a trained model, and writes the recognised text into a new invisible text layer placed behind the original page image. The visible page is unchanged — every pixel sits where it did. Underneath, a positioned text stream now mirrors what is visually on the page, so Cmd+F search works, copy-paste extracts words, and screen readers can read the document aloud.

This dual-layer architecture is what makes "searchable scanned PDF" possible: the visual fidelity of the original scan plus the searchability of a born-digital document, in a single file.

Six OCR engines compared

Tesseract is the engine that underlies every free OCR option on the table — ocrmypdf wraps it for PDFs, ScoutMyTool runs Tesseract.js (the WebAssembly port) in the browser. Tesseract has been developed continuously since 1985 (originally at HP), open-sourced in 2005, and is now maintained by Google.² The current LSTM-based v5 engine is the right default for most workflows; cloud OCRs win on degraded scans and handwriting, but at the cost of uploading the document.

Seven factors that decide OCR accuracy

"OCR accuracy" varies from "near-perfect" to "useless" depending almost entirely on input quality. Optimise these seven factors at scan time and you can usually skip cloud OCR; let any of them slip and even cloud OCR will struggle.

The National Archives (NARA) digitisation guidelines specifically call for ≥300 DPI for printed text and ≥400 DPI for documents with smaller print sizes — these thresholds reflect what OCR engines need to be reliable.³ Scanning below this threshold to save disk space is a false economy if you ever plan to OCR the result.

Adding OCR via ScoutMyTool — five steps

1. Open the tool. Go to scoutmytool.com/pdf/pdf-ocr. The page loads as static HTML and the OCR runs entirely in your browser tab using Tesseract.js.
2. Drop in the scanned PDF. The tool parses the file with pdf-lib and rasterises each page to a canvas at the existing scan resolution.
3. Pick the language(s). Default is English; the picker shows the most-common languages. Pick multiple if your document is multilingual; be sparing because additional languages slow recognition.
4. Run OCR. The tool walks every page, performs OCR, and writes the recognised text into a new invisible text layer behind the original image. A progress indicator shows per-page status; expect 2–10 seconds per page on modern hardware.
5. Download and verify. The output PDF has the same visual content plus a searchable layer. Verify by opening in any reader and pressing Cmd+F / Ctrl+F — should now find words. For higher-stakes documents, spot-check the recognised text against the visual content on a few pages.

The CLI path — ocrmypdf for batch jobs

For batch OCR on a directory of PDFs, the right tool is ocrmypdf — a free command-line wrapper around Tesseract that handles PDF input/output, deskewing, image cleanup, and language selection. Install via apt, brew, or pip; usage is straightforward:

# Single file, English OCR with deskew + cleanup
ocrmypdf --deskew --clean input.pdf output.pdf

# Multi-language (English + French)
ocrmypdf -l eng+fra input.pdf output.pdf

# Batch a directory
for f in *.pdf; do
  ocrmypdf "$f" "ocr_$f"
done

ocrmypdf can also force a re-OCR on a PDF that already has a text layer (useful when the existing layer is wrong), skip pages that already have a good layer (useful for mixed digital-and-scanned documents), and embed colour profiles for archival workflows. For Linux / macOS users, it is the most efficient way to handle hundreds or thousands of PDFs.

Related ScoutMyTool tools and articles

• PDF OCR — the primary tool referenced.
• OCR PDF — alternate entry point to the same OCR engine.
• PDF OCR Extract Text Only — produce a .txt file from a scanned PDF, no PDF rebuild.
• Compress PDF — shrink scanned PDFs before or after OCR.
• PDF to Text — extract text from an already-OCRed PDF.
• Tagged PDF Validator — OCR is the prerequisite for tagging scanned documents.
• PDF accessibility — sister article; OCR is the foundation of accessible scanned PDFs.
• PDF/A conversion — sister article; archive-quality PDFs typically require OCR first.

Frequently asked questions

What does OCR actually do to a PDF?

OCR (Optical Character Recognition) reads the pixels of each page, identifies which pixel clusters form characters, recognises which character each cluster represents, and writes the recognised text into a new invisible text layer that sits behind the original page image. The visible page looks identical; the underlying PDF now contains a searchable, selectable, screen-reader-accessible text layer. The file becomes searchable in any PDF reader, the text can be copied with Cmd+C / Ctrl+C, and accessibility tools can read the document aloud.

Do I need OCR if the PDF was created from a word processor?

No. PDFs exported from Word, Google Docs, LibreOffice, or any digital authoring tool already contain a text layer — every glyph on the page is stored as text, not just as a pixel shape. The PDF is already searchable. OCR is only needed for PDFs whose pages are images: scanned paper documents, photographs of pages, screenshots of text, faxes converted to PDF. To check, open the PDF and try to select a word with click-drag. If the word highlights, you already have a text layer; if nothing highlights, you need OCR.

How accurate is OCR in 2026?

For modern printed text on a clean 300 DPI scan, accuracy is typically 95–99 percent character-level for Latin-script languages, slightly lower for Cyrillic, lower still for CJK, and lowest for Arabic and Indic scripts. Tesseract 5's LSTM engine matches commercial OCR in most cases for clean inputs. Cloud OCR (Google Document AI, Amazon Textract) edges out Tesseract on degraded scans and handwriting. Accuracy drops sharply with low DPI, low contrast, complex multi-column layouts, decorative fonts, and handwriting. For mission-critical accuracy, OCR is a starting point that needs human review, not a final answer.

Which OCR tool should I pick — offline or cloud?

Offline (Tesseract, ocrmypdf, ScoutMyTool) for: confidential documents that should not leave your machine; bulk processing where per-page cloud cost would add up; one-off small jobs where setup overhead of cloud accounts is not worth it. Cloud (Google Document AI, AWS Textract, Azure Form Recognizer) for: degraded scans where local OCR accuracy is insufficient; structured-data extraction from forms or tables; very large batches where the cloud provider's scaling matters more than the per-page cost. For the privacy-conscious default, offline wins; for the highest accuracy on hard inputs, cloud wins.

How do I OCR a multi-language document?

Tell the engine which languages to expect. Tesseract accepts a -l flag with one or more language codes: -l eng+fra runs both English and French recognition; -l chi_sim+eng runs simplified Chinese + English. ScoutMyTool exposes a language picker in the UI. Without the hint, the engine uses a default (usually English) and produces garbled output for other-language portions. Adding too many languages slows recognition and can hurt accuracy on the dominant language; pick the smallest set that covers your document.

Is my PDF uploaded when I use ScoutMyTool OCR?

No. ScoutMyTool's PDF OCR tool runs Tesseract.js — a WebAssembly port of Tesseract — entirely in your browser tab. The PDF is parsed locally with pdf-lib, each page is rasterised to a canvas in the browser, Tesseract.js performs OCR on the canvas, and the recognised text is written into a new text layer in the output PDF. Nothing transits a server. Verify by watching the browser network tab during the operation: zero outbound requests carrying file bytes. For documents containing PII, medical information, or trade secrets, this is materially different from server-uploading OCR services.

Can OCR recover the original layout, or just the text?

It depends on the engine. Tesseract by default produces a flat text layer that follows reading order but loses table structure and multi-column layout. Tesseract's hOCR / ALTO output formats preserve bounding boxes for each word, which post-processing tools use to reconstruct columns and tables. Cloud engines (Google Document AI, Textract) are designed around structured layouts and return tables as structured JSON. For pure search-the-document workflows, flat text is fine; for "extract this scanned spreadsheet into Excel" workflows, a structured-layout engine is worth the cost.