You scan a paper document and get a PDF, but you cannot search it, copy text from it, or edit it. The PDF is just a picture of text. OCR (optical character recognition) solves this by detecting the characters in the image and converting them into actual, machine-readable text. This guide explains how OCR works under the hood, what affects accuracy, and how to get the best results.
Optical character recognition is the technology that reads text from images. It takes an image containing text (a scanned page, a photograph of a sign, a screenshot) and outputs the text as editable, searchable characters. The concept has been around since the 1920s, but modern OCR engines powered by machine learning are dramatically more capable than their predecessors.
In the context of PDFs, OCR is most commonly used to convert scanned documents into searchable PDFs. The original image remains visible, but an invisible text layer is placed on top, allowing you to search, select, and copy text.
Before any character recognition happens, the OCR engine cleans up the input image. Raw scans are rarely perfect. They may be slightly rotated, have uneven lighting, contain speckles from dust on the scanner glass, or have low contrast between text and background.
Common preprocessing steps include:
This is the core of OCR. The engine examines each text region and identifies individual characters. Modern engines use two main approaches, often combined:
Pattern matching compares each character shape against a library of known character templates. It works well for standard printed fonts but struggles with unusual typefaces or degraded text. This was the dominant approach in early OCR systems.
Machine learning (neural networks) is the modern approach. Instead of comparing against templates, a trained neural network analyzes the visual features of each character and predicts what it is. Deep learning models can handle a wide variety of fonts, sizes, and degradation levels because they learn from millions of examples during training.
Most current OCR engines, including Tesseract (the most widely used open-source engine), use LSTM (long short-term memory) neural networks that process text as sequences rather than individual characters. This allows the model to use context: if it is unsure whether a character is an "l" or a "1", it considers the surrounding characters to make a better prediction.
After character recognition, the raw output is cleaned up:
OCR is not magic, and results vary enormously depending on the input. Here are the factors that matter most:
This is the single biggest factor. A clean, high-resolution scan (300 DPI or higher) of a well-printed document will produce near-perfect results. A blurry photograph of a crumpled page will produce garbage. Invest time in getting a good scan, and you will save far more time on corrections.
Standard serif and sans-serif fonts (Times New Roman, Arial, Helvetica, Calibri) are recognized with very high accuracy. Decorative fonts, script fonts, very small text (below 8pt), and very large display text can cause problems. Monospaced fonts like Courier are usually recognized well.
OCR accuracy varies by language. Latin-alphabet languages with large training datasets (English, French, German, Spanish) achieve the highest accuracy. Languages with complex scripts (Arabic, Chinese, Japanese, Korean, Thai) require specialized models and may have lower accuracy. Mixed-language documents can confuse engines that expect a single language.
Faded ink, yellowed paper, coffee stains, creases, and handwritten annotations all reduce accuracy. Historical documents with archaic typefaces pose particular challenges. If you are digitizing old documents, expect to spend time on manual corrections.
Single-column text is easiest. Multi-column layouts, tables, sidebars, footnotes, and text that wraps around images are harder. The layout analysis stage must correctly identify the reading order, and errors here cause the output to be scrambled even if individual characters are recognized correctly.
Follow these practices to maximize accuracy:
OCR tools fall into two categories based on where the processing happens:
Traditional OCR services upload your document to a server, process it there, and return the result. This allows the service to use powerful hardware and large models. The downsides are privacy (your document sits on someone else's server), dependency on an internet connection, and potential file size limits.
Modern JavaScript engines and WebAssembly have made it possible to run OCR directly in the browser. Libraries like Tesseract.js bring the full Tesseract OCR engine to the client side. Your documents never leave your device.
The tradeoff is speed. Browser-based OCR runs on your device's hardware, which is typically slower than a dedicated server. A 10-page scanned document might take 30 seconds to a few minutes in the browser versus a few seconds on a server. For most users and document sizes, this is an acceptable tradeoff for the privacy benefit.
The meldpdf OCR PDF and Extract Text tools process everything in your browser. No data is uploaded.
OCR has real limits that are important to understand:
Modern OCR engines achieve 95-99% character accuracy on clean, well-scanned documents with standard fonts. Accuracy drops significantly with poor scan quality, handwriting, unusual fonts, or complex layouts. A 99% accuracy rate still means roughly one error per 100 characters, so proofreading is always recommended for important documents.
Basic OCR engines struggle with handwriting. Specialized handwriting recognition (ICR or intelligent character recognition) exists but is far less accurate than printed text recognition. Neat, consistent handwriting in block letters produces usable results. Cursive or messy handwriting remains very difficult for any automated system.
It depends on the tool. Browser-based OCR that runs entirely in your browser using JavaScript or WebAssembly (like meldpdf) never sends your files to a server. Other tools labeled as browser-based may still upload files for server-side processing. Check whether the tool explicitly states that processing happens locally.
Last updated: 3 September 2026.