Workflow 7 min read 12 October 2026

PDF OCR Guide: Making Scanned Documents Searchable and Editable

OCR (Optical Character Recognition) converts scanned PDF images into searchable, selectable text. This guide explains how PDF OCR works, the best free and commercial tools, how to verify OCR quality, and what to do when OCR produces incorrect results — including handling handwriting, tables, and multi-language documents.

A scanned PDF is, at its core, nothing more than a collection of page images. The text you see on screen is drawn as pixels — there is no underlying character data, no searchable text layer, no way for a screen reader or copy-paste to access the words. OCR (Optical Character Recognition) fixes this by analysing those images and generating a text layer that overlays the original scan, making the document searchable, accessible, and extractable. Understanding how OCR works in PDF — how the text layer is stored, how accuracy is measured, and how to choose the right tool for your volume and quality requirements — is essential for anyone working with scanned document archives, legacy PDFs, or image-based content from scanners and cameras.

How OCR text layers are stored in PDF

When OCR is applied to a scanned PDF, the recognised text is added as an invisible text layer beneath (or over) the original image. The result is a PDF that contains both the original scan image and a text content stream. The hidden text layer — OCR text is typically rendered with a render mode of 3 (Tr 3 in PDF content stream syntax — "invisible text"). The text characters are positioned to align with the corresponding glyphs in the scan image, but they are rendered with zero opacity. This allows text selection, search, and extraction to work on the positioned invisible text while the visible rendering comes from the image. Glyph positioning precision — High-quality OCR tools position each recognised character precisely over its scan location. Lower-quality tools may position text at line level rather than character level, which affects copy-paste accuracy and accessibility — a screen reader that reads the text layer gets the right words but potentially in wrong order if line positioning is imprecise. Font embedding in OCR output — OCR text layers use embedded fonts. Since the text is invisible, font appearance doesn't matter, but the font must be embedded for PDF/A compliance. Many OCR tools use a generic CIDFont for the text layer. The /ToUnicode CMap must map every glyph to its Unicode code point — without it, text extraction works visually but copy-paste fails. See PDF Font Embedding for more on /ToUnicode requirements. Searchable PDF vs text-only PDF — "Searchable PDF" is OCR terminology for the image-plus-text-layer result. It is distinct from a "text PDF" generated directly from a word processor, where text is rendered visibly from font outlines. In a searchable PDF, visual rendering is always the scan image — the text layer is only there for machine access.

OCR accuracy: factors and measurement

OCR accuracy is not a single number — it varies significantly with document characteristics and is measured at character level, word level, and line level. Character accuracy rate (CAR) — The percentage of individual characters correctly recognised. A state-of-the-art OCR engine on clean, printed, Latin-script text achieves 99.5%+ CAR. At 99% CAR, a 500-word page has ~25 incorrect characters; at 95% CAR, roughly 125 errors per page — enough to make extracted text unreliable for automated processing. Factors that reduce accuracy: - Image resolution: OCR engines perform best at 300 DPI or higher. Below 200 DPI, accuracy drops significantly. Scans at 150 DPI or lower are often unusable for high-accuracy OCR. - Font and type quality: Clear, high-contrast, printed text is easiest. Handwriting, cursive, decorative fonts, and damaged type all reduce accuracy. - Document condition: Stains, creases, perforations, stamps over text, and bleed-through from double-sided printing all introduce noise. - Language and script: OCR engines are trained on language-specific corpora. Accuracy for Latin scripts (English, French, German) is highest; Arabic, Hebrew, CJK, and Indic scripts require specialised language packs and generally have lower baseline accuracy. - Columns and complex layouts: Multi-column layouts, tables, and mixed text/image pages require layout analysis before OCR — text in the wrong reading order undermines usefulness even if character-level accuracy is high. Measuring quality — Ground truth comparison (comparing OCR output to manually verified text) is the rigorous method. For large archives, sampling-based quality audits are practical: randomly select 1% of pages, verify manually, extrapolate accuracy rate. Tools like ocr-evaluator and ISRI OCR evaluation tools automate comparison.

OCR tools: Tesseract, Acrobat, and cloud APIs

Tesseract OCR — The most widely used open-source OCR engine, originally developed by HP and now maintained by Google. Tesseract 4+ uses LSTM (neural network) recognition and achieves competitive accuracy with commercial engines for clean printed text. Available via command line: tesseract input.pdf output pdf produces a searchable PDF. Python integration via pytesseract or via ocrmypdf (which wraps Tesseract for PDF-specific workflows with PDF/A output support). github.com/tesseract-ocr/tesseract ocrmypdf — A Python command-line tool specifically for adding OCR text layers to existing PDFs. It wraps Tesseract, handles multi-page PDFs, optionally produces PDF/A-1b or PDF/A-2b output, deskews images, cleans scans, and validates output. ocrmypdf.readthedocs.io Adobe Acrobat Pro OCR — Acrobat's "Recognise Text" function uses Adobe's OCR engine. Strong on complex layouts and produces well-structured text layers. Integration with Acrobat's PDF/A conversion workflow makes it suitable for archiving pipelines. Best for desktop workflows with moderate volumes. Cloud OCR APIs: - AWS Textract: Extracts text, tables, and form fields from scanned documents. Particularly strong on forms. Returns structured data (key-value pairs for forms, cell data for tables) not just plain text. - Google Document AI: High accuracy across document types, strong multilingual support, specialised processors for invoices, identity documents, and lending forms. - Azure Document Intelligence (formerly Form Recognizer): Similar capability profile. Preferred in Microsoft-stack organisations. Cloud APIs are best for high-volume, automated pipelines where cost per page is acceptable (typically $0.001–$0.01 per page). For on-premises processing of sensitive documents, Tesseract/ocrmypdf remains the standard.

OCR for PDF/A archiving and accessibility

OCR output must meet additional requirements when the target format is PDF/A for archiving or when accessibility is a goal. PDF/A-1b for OCR output — The most common target is PDF/A-1b (basic conformance, no tagging required). The OCR text layer must: embed all fonts (the OCR font for the invisible text layer), include a /ToUnicode map for all glyphs, not reference external content, and include XMP metadata with the PDF/A conformance schema. ocrmypdf --output-type pdfa-1 produces PDF/A-1b compliant output using Ghostscript for the conversion step. PDF/A-2a for accessible OCR — To produce an accessible, tagged searchable PDF from a scan, OCR alone is insufficient — you also need to tag the text layer with semantic structure (/P paragraphs, /H1–H6 headings, etc.). This is difficult because OCR engines typically output a flat text layer without structure. Tools like ABBYY FineReader and commercial remediation tools can produce tagged OCR output. For most scanned archive workflows, PDF/A-1b (searchable but not tagged) is the practical target. Validation after OCR — Always validate OCR output: 1. Open the PDF and use Ctrl+F (Find) to search for a known word — confirms the text layer is present and searchable. 2. Copy-paste a paragraph and check it against the original — confirms /ToUnicode mapping is correct. 3. Run pdffonts to verify font embedding. 4. For PDF/A, validate with veraPDF.

Frequently asked questions

How do I OCR a scanned PDF to make it searchable?

The easiest command-line method is ocrmypdf (free, open-source): install with pip install ocrmypdf, then run: ocrmypdf input.pdf output.pdf. This adds an OCR text layer using Tesseract and produces a searchable PDF. For PDF/A output: ocrmypdf --output-type pdfa-2 input.pdf output.pdf. In Adobe Acrobat Pro: open the scanned PDF, choose Tools > Scan & OCR > Recognise Text > In This File. For a cloud option, Google Drive automatically OCRs uploaded PDFs — open a PDF in Google Drive and it becomes searchable and copy-pasteable. For bulk processing of large archives, ocrmypdf supports batch processing and parallel workers.

How can I tell if a PDF already has a text layer?

Try Ctrl+F (Find) in your PDF viewer — if you can search for words and they are found, a text layer exists. Try selecting and copying text — if you get readable text on the clipboard, the text layer is functioning. In Adobe Acrobat, choose File > Properties > Description tab — a PDF with an OCR text layer will often show the OCR tool in the Creator or Producer field. At the command line: pdftotext document.pdf - | head -20 (from Poppler) extracts text to standard output; if it returns readable text, a text layer is present. PyMuPDF in Python: import fitz; doc = fitz.open("file.pdf"); print(doc[0].get_text()) — readable output means a text layer exists.

Does OCR accuracy matter for PDF accessibility?

Yes, significantly. OCR accuracy is the foundation of any accessibility or downstream processing built on it. A screen reader reading an OCR text layer with 95% character accuracy will mispronounce or misread approximately 1 word in 20 — enough to make technical content incomprehensible. For accessibility, OCR text must also be in correct reading order (crucial for multi-column layouts and tables), which requires layout analysis beyond just character recognition. Cloud OCR APIs (AWS Textract, Google Document AI) include layout analysis and are generally more accessible-friendly for complex documents than basic Tesseract output. For legal, medical, or technical documents, accuracy thresholds of 99%+ are needed to avoid errors that could have real-world consequences.

What resolution should I scan at for best OCR results?

300 DPI is the standard minimum for good OCR accuracy on printed text. 400 DPI is better for small type (under 10pt) or slightly degraded documents. 600 DPI provides diminishing OCR returns over 400 DPI for most printed text but is useful for very fine print, halftones, or documents that will also need high-quality image reproduction. Above 600 DPI, file size grows substantially with little OCR benefit. For handwritten text, resolution helps less than other factors (pen type, paper quality, ink contrast). Scan in greyscale or colour (not black-and-white/bitonal) — many OCR engines achieve better accuracy with greyscale because fine stroke details are preserved. You can convert to bitonal after OCR if file size is a concern.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Edit PDF Add text to PDF Compress PDF Open editor