How to choose an OCR engine for your documents

Most teams choose an OCR engine from a demo, a leaderboard, or whatever their cloud provider offers. Then the real documents arrive: a crooked scan, a phone photo of a form, a table of figures saved as a low-quality JPEG. The engine that looked perfect in the demo now misreads an amount, drops a line, or confidently returns text that is not on the page. Usually nobody notices until the number is already in a database.

What we tested

We drew 25 pages from text we wrote ourselves, so the correct answer is known to the character. Each page reproduces one way documents arrive in real life. The letters, forms and tables are fictional: a harbour authority's tariff letter, a vessel arrival form, a statement of operations.

• Text layer: a born-digital PDF, and a PDF whose hidden text layer is garbled
• Scan quality: clean 300 dpi, 150 dpi, 100 dpi, out of focus, heavy JPEG, noisy photocopy, faded print, phone photo, yellowed paper with show-through
• Geometry: crooked by 4 degrees, sideways, upside down
• Layout: two columns, a ruled financial table, the same table without rules
• Content: 6–7 pt footnotes, look-alike codes, a form filled in by hand, five European languages, a DRAFT watermark, white-on-dark text, words cut off at the page edge, a blank page with specks

The engines are all free and ran on one laptop, CPU only: Tesseract 5, RapidOCR (PaddleOCR's models on ONNX Runtime), PaddleOCR 3 and Docling from IBM, plus the PDF's own text layer where one exists. Tesseract and RapidOCR also ran a second time with automatic preprocessing (rotate, deskew, upscale, flatten the background, remove table rules), shown as + prep.

How we scored

Every word of the correct text lands in exactly one bucket, and every extra word the engine produces is counted too.

We also track key values separately: the amounts, dates, reference numbers and names that a business process depends on. A page can be 98% right and still wrong in the one number that matters, so key values are what we rank by.

The results

On the averages, RapidOCR gets the most key values right (96.2%) at 2.3 seconds a page. Plain Tesseract comes last (70.4%), but with preprocessing it rises to 92.6% and is still the fastest engine at 0.8 seconds. PaddleOCR and Docling are close on accuracy but much slower on a CPU: 66 and 20 seconds a page. The averages hide the most useful part, though. Here is every page:

What we learned

1. Don't OCR a page that already contains its text

A PDF exported from Word or InDesign already holds its text. Reading it took 0.005 seconds and was 100% correct. OCR on the same page took between 0.8 and 66 seconds and could only add errors. The text layer can also lie, though. Our second PDF looks identical on screen, yet its hidden text is garbage, as happens with a broken font encoding or a failed old OCR pass. Trusting it scores 0.7%. A quick check of whether the text looks like words catches it. So the first step of any pipeline is triage, not OCR.

2. A cheap fix beat a bigger model on tables

Plain Tesseract got 18% of the figures right on our ruled financial table, and 22% on the JPEG copy of it. The same table without ruling lines scored 100%. The rules break Tesseract's line finding, and it returns fragments like Totareveue—SSS. Painting long straight lines white before OCR, a few lines of OpenCV, took it to 100% on both. The heavier engines coped with rules on their own, but at 3 to 80 times the time per page.

3. Preprocessing has to be decided per page

The same preprocessing that fixed tables made other pages worse. Contrast stretching cost RapidOCR 23 points of key values on the faded page, and despeckling cost Tesseract on the photocopy. Upscaling the 150 dpi table on its own made Tesseract worse, until the rules were removed too. Fixes should follow from what triage finds on each page, not be applied to everything.

4. Every engine read the look-alike codes the same wrong way

All six configurations turned 0O1l-7B8-IS5 into 0011-7B8-IS5, and Q0-2026-O8 into Q0-2026-08. Tesseract also dropped the subscript in HCO3 and the × sign. No engine fixes this on its own, because in many fonts those characters really are ambiguous. The fix sits outside OCR: validate codes against their format (check digits, known prefixes, a lookup in your own records) and send failures to a person.

5. Noise turns into digits

On the noisy photocopy, no engine got more than 73% of key values. The worst errors are the plausible ones. Tesseract read a gross tonnage of 23,540 as 123,540, because a speck became a 1, and a length of 187.4 as 167.4. Both pass any "is this a number?" check. Only a business rule, such as a cross-check against another field, or a person would catch them.

6. Handwriting and accents split the field

On the handwritten form, plain Tesseract got none of the answers exactly right: it read MARIS AURORA as SMARTS AURORA and 23,540 as 23500. RapidOCR and Docling got 82 to 91%, with errors like 03/04/2026 read as 03104/2026. On the five-language page, Tesseract with its default English model turned Þórður into bordur and Gebühren into Gebthren, getting 20% of the key words. The other three engines got every accented word right. Tesseract does better with the right language packs installed, and that is exactly the kind of detail a demo never shows.

7. Engines miss what the document is, not just what it says

Our watermarked letter carries a large diagonal "DRAFT – NOT FOR EXECUTION". Tesseract, PaddleOCR and Docling returned the letter and left the watermark out entirely. RapidOCR caught the word DRAFT but not the rest. For a contract or a claim, that watermark decides whether the document can be acted on at all. If document status matters in your process, check for it separately.

8. Some engines find text on blank pages

On a blank separator page with scanner dust, Tesseract returned 3 words and PaddleOCR 6. Triage recognised the blank page and skipped it, which is why the + prep version got it right. One result was reassuring: on words cut off at the page edge (REQUISITION NUMBE), none of these engines "completed" the word. General-purpose AI models are more tempted to, which is why the test is there.

9. Speed is a design decision

At 0.8 seconds a page, Tesseract with preprocessing gets through 10,000 pages in about two and a quarter hours on one laptop. PaddleOCR with default settings on the same CPU would need about a week. A GPU and tuned settings change that a lot, but the point stands: the engine you choose sets your hardware bill, and the cheapest setup sends each page to the lightest engine that handles it.

Run the same test on your documents

Our pages are synthetic on purpose, so every error can be traced to its cause. They show how engines fail. Only your own pages show how often. The tool we built for this post, ocr-bakeoff, runs on your own computer. Nothing is uploaded unless you add a cloud engine yourself.

pip install -r requirements.txt
python -m ocrbakeoff demo --open           # the 25 pages from this post
python -m ocrbakeoff serve                 # the same, from a web page
python -m ocrbakeoff run my-scans/ --truth my-truth/ --open

The output is one HTML report plus results.json, results.csv and every engine's raw text, so you can check any number yourself.

We are preparing the code for public release. Until then, email us and we will send it to you.

Limits of this test

• One page per scenario. It shows how each engine fails, not how often. Your own sample tells you that.
• The handwriting is a handwriting-style font, which is easier than real handwriting.
• We used default settings. Every engine can be tuned, and tuning is part of choosing one.
• Timings are for one laptop CPU. Compare engines within this run, not against other benchmarks.
• This measures words and values, not table structure (which cell a number belongs to). That needs a different check, which we will cover in a later post.
• We did not include commercial cloud engines or large vision-language models. The tool supports them, and we will add them in a follow-up.