How to Extract Text from a Scanned PDF: OCR Explained

Recognize and copy text from scanned PDFs using OCR that runs entirely in your browser. Learn how Tesseract works, when it fails, and how to maximize accuracy on real documents.

7 min read

Digital PDFs vs scanned PDFs

The most common frustration with PDFs is discovering that you cannot select the text. You open the file, try to copy a paragraph, and the cursor slides right through, as if it were a picture. That is because it is a picture.

PDFs come in two flavours:

Digital PDFs. Generated from software like Word, LibreOffice, a web browser, or LaTeX. The text is stored as encoded characters (a T, an e, an x, and a t) with positioning information. You can select, copy, and search this text.

Scanned PDFs. Generated from a scanner, phone camera, or "print-to-PDF" from an image. Each page is a raster image (usually JPEG or PNG) embedded in a PDF wrapper. There is no text layer. Selecting text is impossible because there is no text to select.

The way you turn a scanned PDF into something you can search or copy is called optical character recognition (OCR). This guide covers what OCR actually does, how to run it in your browser without uploading sensitive scans, and how to get the best results on tricky documents.

What OCR does, in one paragraph

OCR looks at each pixel of an image and tries to recognize letters and words. Modern engines break this into three phases: preprocessing (deskewing, binarising, denoising), layout analysis (finding lines, words, and paragraphs), and character recognition (mapping shapes to Unicode using a trained model). The output is a stream of text with approximate positioning information, enough to overlay an invisible text layer on top of the original image so you get a searchable scanned PDF.

Running OCR in your browser

Our OCR tool uses Tesseract.js, a WebAssembly port of Google's Tesseract OCR engine, running entirely in your browser. Here is the flow:

1. Open the scanned PDF

Drag the file onto the drop area. The tool renders each page to a canvas at 2× scale (higher than the default 1× because OCR accuracy scales strongly with resolution). Rendering happens locally using pdf.js.

2. Select the document language

This step matters more than you might think. Tesseract ships separate language models for over 100 languages, and picking the right one raises accuracy substantially. If your document is mostly English with some French quotes, pick English; multi-language documents can also be recognised with a combined language code like eng+fra, but accuracy drops slightly for both.

Common languages:

  • eng (English)
  • chi_sim (Chinese Simplified)
  • chi_tra (Chinese Traditional)
  • jpn (Japanese)
  • spa (Spanish)
  • fra (French)
  • deu (German)
  • kor (Korean)

3. Choose the output format

Two options:

Plain text. All recognised text, roughly in reading order, exported as a .txt file. Best when you plan to feed the text into another tool (a translator, a database, a search index).

Searchable PDF. The original scan with an invisible text layer overlaid on top. Visually indistinguishable from the input, but you can Ctrl+F to search, and text selection works. Best when you need to keep the original document appearance.

4. Process and download

Recognition runs page by page. Expect roughly 2-5 seconds per page on a typical modern laptop, depending on page complexity. The tool shows progress as pages complete.

Why the first run is slow

The first time you OCR a document in a new browser session, the tool downloads the language model for your chosen language. Model sizes range from 4 MB (English) to 50 MB (some Asian scripts). Once downloaded, the model is cached by the browser, so subsequent runs are much faster.

Two implications:

  • First-time users: the initial page can appear to hang for 10-30 seconds while the model downloads. This is not the tool failing; it is a one-off cost.
  • Offline use: after the first successful run, the language model is in your browser cache. Subsequent runs work without a network connection.

If your browser aggressively clears its cache (private/incognito mode, or aggressive tab suspension), you may see the download cost every session. Regular browsing profiles preserve the cache.

Getting the best OCR accuracy

OCR accuracy on production documents is not the same as accuracy on clean, high-contrast test images. Real documents have shadows, skew, noise, mixed fonts, and coffee stains. Here is what actually helps:

Scan at 300 DPI or higher. OCR engines are trained on 300 DPI images. Below that, character shapes lose enough detail that the model starts confusing similar letters (l vs 1 vs I, O vs 0, rn vs m). If you can rescan the document at a higher resolution, do it.

Straighten the page. Skew above ~2° drops accuracy rapidly. Tesseract deskews automatically, but only up to about 10°. Anything more crooked than that will produce garbled output. Rescan or use an image editor to rotate.

High contrast, low noise. Yellowed paper, faint carbon copies, and scans from bad-quality copies all reduce accuracy. If your scanner offers a "black and white" or "text mode" setting, use it - those modes threshold the image, effectively removing background noise.

Match the language. Even if you can read the document as English, if it contains German umlauts or Spanish tildes, picking eng+deu (English + German) will beat plain eng.

Use a searchable PDF for text that has to look right. Plain text output loses layout information, paragraphs may run together, columns may interleave, and tables become a mess. Searchable PDF preserves the visual, and only adds text underneath.

Handwriting recognition

Tesseract's default models are trained on printed text. Handwriting recognition is available but experimental, with accuracy typically below 60% for cursive scripts and only marginally better for block letters. If you need to digitise handwriting reliably, use a specialised service, Google Cloud Vision, Microsoft Azure Document Intelligence, or AWS Textract offer handwritten-text models. Those are cloud services, so they trade privacy for accuracy; there is no browser-based equivalent that matches their handwriting quality.

Handling multi-column and table layouts

Layout analysis is where most OCR engines struggle. Tesseract has two levels of layout awareness:

  • Simple mode. Assumes one column, reading top-to-bottom. Fast and accurate on single-column documents. Terrible on newspapers and multi-column reports.
  • Automatic page segmentation. Detects columns, tables, and headers. Slower but produces more coherent reading order.

The tool defaults to automatic segmentation for scanned PDFs. If your output has text jumbled together across columns, the automatic segmentation missed something, usually because the columns are too close together or the gutter is not clean. Workarounds: split each column into its own file with an image editor first, then OCR each separately.

Tables are the worst case. OCR engines recognise the text in table cells, but reconstructing the row/column structure requires a separate module that Tesseract does not have. If your document has critical tabular data, plan to reformat it manually after OCR.

Frequently asked questions

Can OCR work on handwriting?

Barely, and only for block-printed text. Cursive handwriting is not reliably recognised by browser-based OCR. Use a cloud service with a dedicated handwriting model if this is your main use case.

What is the difference between plain text output and a searchable PDF?

Plain text is a .txt file with the recognised words. Searchable PDF is the original scanned image with an invisible text layer added, so the file still looks like the scan but text search and selection work. Use searchable PDF when you need to preserve the visual appearance; use plain text when you plan to feed the content into another tool.

How accurate is OCR on typical documents?

On clean 300 DPI scans of common printed text (Latin scripts, standard fonts), accuracy is typically 95-99%. On lower-quality scans, older documents, or unusual fonts, it can drop to 80% or lower. Non-Latin scripts (Chinese, Japanese, Arabic) tend to be 5-10 percentage points lower.

Why does my output have random punctuation?

Two common causes: dust or specks on the scan being interpreted as periods and commas, and character-shape confusions in the model (a . recognised where there is actually a comma-shaped smudge). Postprocessing with a simple regex to remove implausible sequences (three periods in a row, punctuation with no adjacent letter) can clean this up significantly.

Is my scanned document uploaded when I OCR it in the browser?

No, not with a WebAssembly-based tool. The image is rendered to a canvas in your tab, passed to the Tesseract WASM module, and the recognised text is returned to the same tab. Nothing crosses the network except the initial language-model download.

Can I OCR a 500-page document?

Yes, but plan for it to take a while. At 2-5 seconds per page, 500 pages is roughly 20-40 minutes of solid CPU time in your browser. The tab must remain open and focused; some browsers throttle background tabs. Consider running it overnight.