PDF OCR Guide: How to Turn Scanned Documents Into Searchable Text

What Is OCR and Why It Matters

OCR stands for Optical Character Recognition. It is the process of converting images of text — scanned documents, photographs of contracts, screenshots of PDFs — into actual machine-readable text. Without OCR, a scanned PDF is just a picture: you can look at it, but you cannot search it, copy text out of it, or edit it. With OCR, that same document becomes a real, interactive file.

The difference is practical, not academic. Here is what OCR unlocks:

• Search old tax records. Have 200 pages of scanned receipts from 2015? Without OCR, finding that one deductible expense means skimming every page. With OCR, you type "office supplies" and jump straight to it.
• Copy contract clauses. A scanned lease agreement sent by your landlord. You want to quote the early-termination clause in an email. Without OCR, you retype it. With OCR, you select, copy, paste.
• Make documents accessible. Screen readers for the visually impaired need text, not images. A scanned PDF that passes OCR becomes readable by assistive technology.
• Extract data from forms. Invoices, medical intake forms, shipping manifests — OCR is the first step before any automated data extraction pipeline.

How OCR Actually Works Under the Hood

Modern OCR is a multi-stage pipeline. Understanding these stages helps you diagnose why OCR sometimes gets things wrong and what you can do about it.

1. Preprocessing

Raw scanned documents are messy. The preprocessing stage cleans them up before any recognition happens:

• Despeckle: Removes noise — dust specks on the scanner glass, compression artifacts from fax transmission, random pixels from a low-quality camera photo. Each speckle is small but can confuse character boundaries.
• Deskew: Straightens crooked scans. If you placed the document at a slight angle on the scanner (or took a photo at an angle), the text lines are tilted. Deskewing rotates the image until text lines are horizontal. Most phones and scanners produce 1-3 degrees of skew — barely noticeable to the eye but enough to wreck character segmentation.
• Binarize: Converts the image to pure black and white pixels (a "binary image") using a threshold. Any pixel darker than the threshold becomes black; any pixel lighter becomes white. The threshold choice matters enormously — too aggressive and thin strokes (like the crossbar on a lowercase "e") disappear; too lenient and smudges become part of the character.
• Segment: Identifies regions of the page that contain text versus images, tables, or whitespace. This is harder than it sounds — a document with sidebars, headers, footers, and multi-column layouts requires the OCR engine to reconstruct the correct reading order.

2. Text Detection

Once the image is clean, the engine finds the text elements:

• Line detection: Groups black pixels into horizontal bands at roughly the same vertical position. Each band is a line of text.
• Word segmentation: Within each line, detects whitespace gaps that separate words. This is straightforward for most languages but fails on languages without explicit word boundaries (Japanese, Chinese, Thai).
• Character segmentation: Splits each word into individual character candidates. The hardest part — characters can touch (ligatures like "fi" or "fl"), overlap, or be broken by poor scan quality.

3. Character Recognition

This is where the actual "reading" happens. There are two approaches:

Pattern matching (legacy): Older OCR engines (pre-2015) used template matching. They stored bitmap templates of every character in every supported font. The engine slid each template across the segmented character image and reported the best match. This approach required a template for every font variant — Times New Roman 12pt bold has a different bitmap than Times New Roman 10pt italic. If the document used a font the engine had never seen, accuracy cratered.

Neural network inference (modern): Tesseract 5, Google's current OCR engine, uses an LSTM (Long Short-Term Memory) neural network. Instead of storing font templates, the network learns the abstract features of each character — curves, strokes, junctions, loops — from millions of training examples. The LSTM processes the image left-to-right, character by character, using context from surrounding characters to resolve ambiguity. An "a" that looks like an "o" in isolation becomes clearly an "a" when the network sees "c_ntract" and the language model suggests "contract."

Modern neural OCR handles approximately 200 languages, reads handwriting (neat handwriting at least), and adapts to mixed fonts on the same page without explicit font detection.

4. Postprocessing

The raw output from the neural network still has errors. Postprocessing cleans them up:

• Dictionary validation: Each recognized word is checked against a language dictionary. "C0ntract" (with a zero) becomes "contract." "Teh" becomes "the."
• Context clues: The engine uses surrounding words and sentence structure to correct errors. "Ths is a form" becomes "This is a form" because "This" is the only word that makes sense at the start of a sentence.
• Language model smoothing: A statistical language model predicts the most likely sequence of words. If the raw OCR output reads "I w0rk at the b4nk," the language model recognizes that "work" and "bank" are the only plausible words in context.

Tesseract.js — OCR in Your Browser

Our PDF OCR tool runs on Tesseract.js, a WebAssembly port of the Tesseract 5 OCR engine. Here is what that means for you.

Tesseract began as a proprietary OCR engine at Hewlett-Packard in the 1980s. HP open-sourced it in 2005, and Google has maintained it since 2006. Tesseract 5 (released 2021) replaced the old pattern-matching recognition with an LSTM neural network, producing a dramatic accuracy improvement — roughly 15-20% better character-level accuracy on clean documents compared to Tesseract 4.

Tesseract.js compiles the C++ Tesseract engine into WebAssembly, which runs in your browser at near-native speed. The entire engine — preprocessing pipelines, LSTM inference, postprocessing — executes client-side. Nothing is sent to a server.

What happens when you use the tool:

1. You upload a PDF. The browser reads the file as an ArrayBuffer — a raw byte array. No data leaves memory.
2. Each page is rendered to an image at the native resolution of the PDF. If the PDF was scanned at 300 DPI, the image is 300 DPI.
3. Each page image is fed to the Tesseract.js worker. The worker runs the full OCR pipeline (preprocessing, detection, recognition, postprocessing) in a separate browser thread using Web Workers. The UI stays responsive.
4. Training data files (~10 MB per language) are downloaded on first use and cached by the browser for subsequent sessions. No re-download unless the cache is cleared.
5. The result is either a searchable PDF (the original image layer plus an invisible text layer overlaid) or a plain text file.

OCR Accuracy Factors

Not all scanned documents produce the same OCR quality. Understanding what affects accuracy helps you set expectations and, where possible, improve your source documents before processing.

DPI (Dots Per Inch)

300 DPI is the recommended standard. At 300 DPI, each character occupies roughly 20-30 pixels in width — enough for the LSTM neural network to recognize stroke patterns reliably. Below 150 DPI, a 10pt character is only 8-10 pixels wide. The LSTM has to guess from too little information.

Font Type

• Monospace (Courier, Consolas): Easiest for OCR. Every character has the same width, and the shapes are simple and separated. 99%+ accuracy.
• Sans-serif (Arial, Helvetica, Verdana): Very good. Clean strokes, open counters (the enclosed spaces in letters like "o" and "e"). 98-99% accuracy.
• Serif (Times New Roman, Georgia, Garamond): Slightly harder. Serifs can merge adjacent characters (especially "rn" looking like "m" or "cl" looking like "d"). 95-98% accuracy.
• Script / handwriting fonts: Hardest. Connected cursive strokes defeat character segmentation. Even the LSTM struggles — accuracy can drop to 60-80% depending on how elaborate the font is.

Language

English OCR achieves 98-99% accuracy on clean input because English training data is abundant and Tesseract's default language model is English-heavy. For other languages, accuracy depends on the quality and quantity of the LSTM training data for that language:

• Well-supported (98%+): Spanish, French, German, Italian, Portuguese, Dutch, Russian
• Moderately supported (90-97%): Arabic, Hindi, Chinese (Simplified), Japanese, Korean
• Weakly supported (70-90%): Smaller languages, regional dialects, historical scripts

Mixed-language documents (e.g., an English contract with Latin legal phrases) need the correct language pack. If you process a document with mixed German and English using only the English pack, the German words like "Geschäftsführung" will contain errors because the language model doesn't recognize them.

Document Quality

Real-world documents are rarely pristine scan samples. Common defects and their impact:

Step-by-Step: OCR a Scanned PDF Using Our Tool

1. Open the PDF OCR tool. The page loads a drop zone and configuration panel. No account, no sign-up.
2. Upload your PDF. You can click to select a file or drag-and-drop a PDF onto the drop zone. The tool reads the file metadata — page count, file size, DPI — and displays it.
3. Select language(s). Choose the document language from the dropdown. For multi-language documents, select multiple languages. Tesseract will attempt OCR with each language pack and merge the results. Adding unnecessary languages slows processing and can reduce accuracy (the engine has more character candidates to choose from).
4. Select page range. Process all pages or a specific range. For testing, start with a single page — if the output quality is good, process the rest.
5. Choose output format. Two options:
   • Searchable PDF: Preserves the original visual appearance (the scanned image layer) and adds an invisible text layer beneath it. You can search, select, and copy text while the document looks identical to the original scan.
   • Plain text (TXT): Extracts the text only, with no formatting. Useful as input for data extraction pipelines or when you only need the content.
6. Click "Start OCR." The tool creates a Web Worker for each page and begins processing. A progress bar shows page-by-page completion. Each page takes roughly 10-30 seconds depending on content density, page size, and your CPU.
7. Download the result. Once complete, the tool presents a download button. The searchable PDF opens in any PDF viewer — the text layer is embedded in the PDF metadata. You can now search for any word across the entire document.

Tesseract vs Cloud OCR APIs

Browser-based Tesseract is free and private. Cloud OCR APIs are faster and more accurate on complex documents. Here is a direct comparison to help you decide which approach suits your use case.

When to use each

Use Tesseract.js (browser) when:

• Privacy matters — legal, medical, financial documents
• You need zero setup cost and zero ongoing cost
• Your documents are cleanly scanned printed text
• You process fewer than 100 pages per week
• You don't want to manage API keys, billing, or rate limits

Use a cloud API when:

• You need to extract table structure or form key-value pairs (AWS Textract)
• Documents contain heavy handwriting (cursive, messy signatures)
• You process thousands of pages at scale
• Speed matters more than privacy
• You are building an automated document pipeline with downstream processing

For most individual users and small businesses, Tesseract.js is more than good enough. The 98-99% accuracy on clean printed documents covers the vast majority of real-world use cases — old reports, scanned books, archived invoices, historical letters. Cloud APIs start to justify their cost only when you need handwriting recognition or structured table extraction.

When OCR Fails and What to Do

No OCR engine is perfect. Here are the most common failure modes and how to handle them.

Handwriting

Tesseract's LSTM handles neat, block-print handwriting reasonably well (~90% character accuracy on capital letters). Cursive handwriting is another story — accuracy drops to approximately 50% for linked cursive, especially when the writing style is idiosyncratic. The neural network doesn't have enough training data for the near-infinite variety of human handwriting.

What to do: For handwritten documents, use a cloud API (Google Cloud Vision or AWS Textract). If the handwriting is critical and you must stay private, the only reliable solution is manual transcription.

Distorted or Faded Text

A document printed on a dot-matrix printer in 1985, stored in a basement for 30 years, then scanned on a consumer flatbed — the characters are faded, broken, and uneven. The LSTM sees fragments where there should be full strokes.

What to do: Increase contrast in preprocessing. Our PDF OCR tool applies adaptive thresholding by default — it calculates a local threshold for each pixel region rather than a single global threshold. This helps with uneven illumination. For severely faded text, try the "high contrast" option if available, or scan at a higher DPI (600 DPI can sometimes recover details lost at 300 DPI).

Mathematical Notation

Standard OCR engines, including Tesseract, are not trained on mathematical notation. An equation like "∫₀^∞ e^{-x²} dx = √π / 2" will be recognized as a jumble of unrelated symbols — the integral sign might become a stretched "S," the Greek letters might be misidentified, and the superscript/subscript relationships are lost entirely.

What to do: Do not use general-purpose OCR for math documents. Use MathPix (API-based, specialized in LaTeX math recognition) or InftyReader for scientific documents. For a free alternative, render the document as images and use a LaTeX OCR service — but expect to manually correct the output.

Tables

Tesseract reads tables left-to-right and top-to-bottom, but it does not preserve table structure. It outputs cell contents in reading order as a flat text stream — you lose which cell belonged to which row and column. The engine has no concept of merged cells, table headers, or hierarchical row relationships.

What to do: If the table structure is essential, use AWS Textract (best in class for table extraction) or Tabula (a free, open-source tool specifically for extracting tables from PDFs, though it works better on text PDFs than scanned images). For simple tables, manual copy-paste with spatial awareness is often faster than correcting broken OCR output.

Non-Latin Scripts

Tesseract supports Arabic, Chinese (Simplified and Traditional), Japanese, Korean, Hindi, Thai, and many other scripts — but you must download the correct trained data files. The English pack cannot recognize Chinese characters, and the Chinese pack cannot recognize Devanagari.

What to do: In our tool, select the correct language from the language dropdown before starting OCR. For CJK (Chinese, Japanese, Korean) documents, download the script-specific trained data (chi_sim, chi_tra, jpn, kor). These trained data files are larger than the Latin language packs (~15-30 MB versus ~10 MB for English) because CJK scripts have thousands of characters. The first-time download takes longer, but subsequent uses are instant (browser cache).

The Privacy Advantage of Browser OCR

This is the most important section of this guide.

When you upload a document to a cloud OCR service — Google Cloud Vision, AWS Textract, Adobe Acrobat Online, any online "PDF to text" converter — your document is transmitted over the internet, stored on the provider's servers (at least temporarily), processed on their infrastructure, and potentially retained in logs, training data, or cached output.

For many documents, this is fine. A public company's annual report is not sensitive. But consider:

• Tax returns — contain Social Security numbers, income details, bank account numbers
• Medical records — protected by HIPAA in the US. Sending them to a third-party server without a Business Associate Agreement is a compliance violation.
• Legal contracts — protected by attorney-client privilege. Sending privileged documents to a third party can waive that privilege.
• Trade secrets — manufacturing specifications, proprietary formulas, unreleased product designs
• Personnel files — employment agreements, performance reviews, disciplinary records

Browser-based OCR using Tesseract.js avoids all of these problems because the document never leaves your device:

• No network transmission. The PDF is read into browser memory locally. No data is sent over the network — not even the file name.
• No server processing. Every CPU cycle happens in your browser's Web Workers on your own hardware.
• No data retention. When you close the browser tab, the PDF data in memory is garbage-collected. Nothing is written to disk (except the output file you choose to download).
• No API keys. No accounts, no billing, no audit logs. There is nothing to leak.
• No third-party dependency. Even if the Tesseract.js library had a vulnerability (which is extremely unlikely — it is a widely audited open-source project), the attacker would need to exploit it through your browser sandbox, which is already one of the most secure execution environments in computing.

Ready to OCR your scanned PDF?
Open PDF OCR Tool →
No upload. No server. Your document stays on your device.