# How Accurate Is OCR? Real Numbers and Why It Is Never 100%

> No OCR is 100% accurate. Clean print reads at 97-99% per character, hard documents at 58-91% in our test. See why 99% still breaks fields and how to fix it.

**In short:** No OCR is 100% accurate: clean printed text reads at about 97-99% per character, but tables, handwriting and phone photos scored 58-91% in our benchmark. Even 99% means about 10 wrong characters per 1,000, which hurts most at field level, where one wrong digit ruins a whole number.

**Canonical URL:** https://docsapi.co/resources/blogs/understanding-ocr-accuracy-metrics-challenges-and-improvement-strategies
**Author:** Nupura Ughade — Content Marketing Lead, DocsAPI
**Author LinkedIn:** https://www.linkedin.com/in/nupura-ughade/
**Published:** 2025-05-28T00:00:00.000Z
**Updated:** October 12, 2026
**Primary topic:** how accurate is ocr
**Site:** https://docsapi.co (DocsAPI — Document AI & OCR API for SMB Lending)

---

No OCR (optical character recognition, software that turns pictures of text into text) is 100 percent accurate. Clean printed pages read at about 97-99% per character, while tables, handwriting and phone photos scored 58-91% in our benchmark. Even 99% leaves about 10 wrong characters per 1,000, which breaks whole fields more often than the number suggests. Below: the numbers, what lowers accuracy, and how to raise it.

## How accurate is OCR on real documents?

It depends on the document far more than on the engine. In our benchmark of 1,700 real documents, clean typed English scored 97-99% character accuracy on all three OCR engines we compared. Scanned bank statements, phone-photographed receipts, multilingual pages and handwriting scored between 58% and 91%, and the best engine changed by category.

| Document category | Tesseract 5.x | PaddleOCR | DocsAPI |
| --- | --- | --- | --- |
| Typed English (clean) | 97-99% | 97-99% | 97-99% |
| Scanned bank statements (multi-page tables) | 64% | 79% | 91% |
| Phone-photographed receipts (low quality) | 58% | 82% | 76% |
| Multilingual (English + Mandarin/Spanish) | 71% | 89% | 81% |
| Handwritten forms (mixed neatness) | 61% | 73% | 78% |

These are character-level scores on the 500-document engine comparison set in our [OCR accuracy benchmark for 2026](/resources/blogs/ocr-accuracy-benchmark-2026), scored against hand-labeled ground truth (an answer key a person made by hand). DocsAPI is our product, and we report where it loses: it trails PaddleOCR on phone-photographed receipts and multilingual pages.

On clean print the engines tie, so accuracy there should not decide your purchase. On the hard categories the gap between the best and worst engine is 17 to 27 points (91% against 64% on bank statements), so engine choice and input quality decide the outcome. Your real accuracy blends the easy and hard rows by your own document mix.

## Is OCR 100 percent accurate?

No. No OCR engine reads scanned or photographed documents with 100 percent accuracy. The software estimates the most likely character for each shape, and look-alikes such as 0 and O or 1 and l, blur and stray marks mean some guesses are wrong. Even the U.S. National Archives says its OCR-built 1950 census name index is not 100-percent accurate.

OCR has nothing to check a guess against except the pixels. If a smudge makes a 5 look like an S, nothing else in the image says which is right, and a serial number or an amount has no surrounding words to help.

### Can OCR be 100 percent accurate in any situation?

For recognizing pictures of text, no: any engine can misread a smudged or look-alike character. Two situations get you to effectively 100%, though, and neither is a better engine. One avoids recognition altogether, and the other catches errors after recognition.

- The PDF already contains text. Files exported from Word or an accounting system usually carry a text layer, so the characters can be copied out exactly and nothing is recognized or misread. A few have broken font encodings and still need OCR. See readable PDF vs image PDF for a 2-second test.
- A pipeline with checks. Rules the data must satisfy (totals add up, check digits pass) plus a person reviewing low-confidence fields can make the data you keep very reliable. That is a property of the process, not the engine, and it costs review time.

### Is there an OCR that is 100 percent accurate? Why vendor claims differ

No. Anyone advertising 100% accurate OCR is measuring something narrower than your job: clean pages, characters instead of fields, or output after a human fixed it. A 99% claim can be true on a clean demo file and still tell you little about your documents. Five differences explain most of it.

| What differs | Effect on the number | What to ask |
| --- | --- | --- |
| What is counted | At 99% per character, about 1 in 10 ten-digit account numbers still has an error. | Character, word or field accuracy? |
| Which documents | Clean print scored 97-99% on every engine we compared. The hard categories scored 58-91%. | Which document types? |
| Before or after correction | A figure taken after human review or validation describes a process, not an engine. | Is this raw engine output? |
| Confidence or measured accuracy | Confidence is the engine's own estimate. D-Lib Magazine (2009) says true accuracy can only be determined by a human. | Measured against what answer key? |
| Average or worst case | A blended average hides the hard categories where errors bunch up. | What is the accuracy on my worst documents? |

Our benchmark write-up says the gap between a vendor headline number and production performance is often 15 to 30 points on hard document types.

## What does an OCR accuracy percentage actually measure?

An OCR accuracy percentage is the share of items the engine got right, checked against an answer key a person made by hand. The item can be a character, a word or a whole field, and the same output scores differently on each. Character accuracy is the most flattering. Field accuracy is the most useful.

| Measure | Formula | Score for the example below |
| --- | --- | --- |
| Character error rate (CER) | (insertions + deletions + substitutions) / characters in the answer key | 1 wrong of 66 characters: CER 1.52%, accuracy 98.48% |
| Word error rate (WER) | (substituted + deleted + inserted words) / words in the answer key | 1 wrong of 10 words: WER 10%, accuracy 90% |
| Field accuracy | fields fully correct / total fields | Total due is wrong, so that field scores 0% |

```
Answer key: Invoice INV-20458 dated 2026-03-14 total due $1,250.00 net 30 days OCR output: Invoice INV-20458 dated 2026-03-14 total due $7,250.00 net 30 days
```

One digit was misread (1 read as 7). We computed the scores with a short Python script using standard edit distance. The line is 98.48% right by character and 90% right by word, yet the amount is 5.8 times too large and would pass any check that only looks at format.

Microsoft's OCR documentation defines word error rate as (S + D + I) / N: substituted, deleted and inserted words over the words in the reference. One scale rates 98-99% as good, 90-98% as average and below 90% as poor (Holley, D-Lib Magazine, 2009, on digitized newspapers), and her 45-page sample ranged from 71% to 98.02%.

## The math: how 99% per character becomes wrong fields

A field is read perfectly only if every character in it is. If each character is right with probability p, a field of N characters is perfect with probability p to the power of N. At 99% per character that gives 92.3% for an 8-character invoice number, 90.4% for a 10-digit account number and 81.8% for a 20-character name.

Formula: chance a field is perfect = p^N. We computed every value below in Python 3.

| Accuracy per character | Wrong characters per 1,000 | 8-character invoice number | 10-digit account number | 20-character name | Whole 1,000-character page |
| --- | --- | --- | --- | --- | --- |
| 99.9% | 1 | 99.2% | 99.0% | 98.0% | 36.8% |
| 99% | 10 | 92.3% | 90.4% | 81.8% | under 0.01% |
| 98% | 20 | 85.1% | 81.7% | 66.8% | under 0.01% |
| 97% | 30 | 78.4% | 73.7% | 54.4% | under 0.01% |
| 95% | 50 | 66.3% | 59.9% | 35.8% | under 0.01% |

```
for p in (0.999, 0.99, 0.98, 0.97, 0.95): print(p, [round(p ** n * 100, 1) for n in (8, 10, 20)])
```

Working backward, to get 99% of 10-digit account numbers fully right you need 99.900% per character (p = 0.99 to the power of 1/N). For an 8-character invoice number it is 99.874%, and for a 20-character name 99.950%. Moving from 99% to 99.9% per character cuts wrong 10-digit account numbers from 9.6% to 1.0%, a tenfold change.

A whole page is far harsher: at 99% per character, a 1,000-character page is error-free about 0.0043% of the time, so design for catching errors, not avoiding them all. One caveat: real errors bunch up on smudged or skewed pages instead of arriving independently, so read the table as a guide to how fast field accuracy falls, not a forecast. For the same idea across every field on a multi-page statement, see our [bank statement OCR pricing analysis](/resources/blogs/bank-statement-ocr-pricing).

## Why is OCR inaccurate on some documents?

OCR does not read the way you do. It converts pixels into the most likely characters with no knowledge of what the document is about. Anything that blurs, tilts, crops or hides a letter raises the chance of a wrong guess, and complex layouts such as multi-page tables add errors that have nothing to do with letter shapes.

What affects OCR accuracy comes down to the seven inputs below. Most are in your control before the file reaches the engine.

| What lowers accuracy | What goes wrong | What to do |
| --- | --- | --- |
| Low resolution or small text | Letters made of too few pixels lose their shapes. Amazon Textract needs text at least 15 pixels tall (8-point at 150 DPI). | Scan at 300 DPI or higher. 8-point text at 300 DPI is about 33 pixels tall (8/72 inch x 300). |
| Skew and rotation | Tesseract's documentation says line segmentation drops significantly on a page that is too skewed. | Rotate upright and deskew (straighten the text lines) before OCR. |
| Low contrast, shadows, noise | Faded print, uneven lighting and speckle confuse the step that turns the image into black and white. | Use even light with no flash glare. Boost contrast and remove speckle. |
| Fonts and busy backgrounds | Tiny or decorative type and text over images or patterns give the engine less to work with. | Ask for the original file when one exists. Avoid photos of screens. |
| Handwriting | Shapes vary between writers. Handwritten forms scored 61-78% in our benchmark. | Ask for typed or block-capital entries. Send handwritten amounts to review (handwritten and faxed invoice data). |
| Tables and layout | Multi-page tables and merged cells split engines most: 64% to 91% on bank statements in our benchmark. | Use a layout-aware engine and check row counts and totals (invoice line-item extraction). |
| Language and script | Mixed English, Mandarin and Spanish pages scored 71-89% in our benchmark. Textract text detection covers six languages. | Set the language to match the page and check the engine's supported list. |

The engine matters too, but mostly on hard documents, so fix the input first and choose the engine second.

## How to improve OCR accuracy: a 10-step checklist

Fix the image first (300 DPI, straight, cropped, high contrast), then the engine settings (language, dictionaries, an engine tested on your document type), then add checks on the fields that matter and send low-confidence results to a person. The 10 steps below follow that order.

1. Check whether you need OCR at all. If the PDF has selectable text, extract it directly.
2. Send the original file. Amazon Textract's guidance is not to convert or downsample a supported file before upload.
3. Scan at 300 DPI or higher. Tesseract's documentation says it works best at 300 DPI or more, and the D-Lib article on newspaper digitization recommends the same.
4. Photograph flat and square-on, in even light. Fill the frame so small print is at least 15 pixels tall, and avoid flash glare and shadows.
5. Crop and rotate upright. Cut away the desk around a phone photo and turn sideways pages. Tesseract recommends a border of about 10 pixels. Our document detection guide covers these steps.
6. Deskew. Straighten tilted text lines before recognition. Heavy skew severely hurts Tesseract's output.
7. Raise contrast and remove noise. Converting to black and white can go wrong on uneven pages, so use adaptive thresholding and remove speckle first.
8. Rescale small images up to about 300 DPI. It helps the engine but cannot restore detail the camera never captured.
9. Set the language, and turn off dictionaries for codes. Tesseract's documentation says turning off its dictionaries should help when most of the text is not dictionary words, as with part numbers and IDs.
10. Validate, route and measure. Check that totals add up and check digits pass, and send low-confidence fields to review. Then score 50 of your own documents against a hand-checked answer key (how to measure OCR accuracy).

Handwriting and multi-page tables respond less to pre-processing. Phone photos respond more: our benchmark write-up says deskew, rotation correction and page boundary detection close most of the gap on phone-photographed receipts.

## How reliable is OCR technology for financial documents?

Reliable enough to do most of the typing, not reliable enough to run unchecked. In our benchmark the best result on multi-page bank statement tables was 91% and on invoice line items 93%. Plan for review, not perfection.

| Test in our benchmark | Weakest result | Strongest result |
| --- | --- | --- |
| Scanned bank statements, multi-page tables (OCR engines) | 64% (Tesseract 5.x) | 91% (DocsAPI) |
| Invoices, line-item extraction (document parsers) | 81% (Docling) | 93% (DocsAPI) |
| Scanned receipts, mobile quality (document parsers) | 58% (Docling) | 78% (LlamaParse) |

The tests score differently: character level for the OCR engines and extraction accuracy for the parsers, so compare results within a row, not across rows.

OCR turns an image into text and fields. It does not decide whether an applicant qualifies, an invoice should be paid or a document is genuine. Those decisions need your rules and, in regulated work such as lending, tax or identity checks, a person and your compliance process. This page is not legal, tax or lending advice.

### Make errors detectable with check digits

The cheapest way to catch an OCR mistake is a rule the data must satisfy. US bank routing numbers have 9 digits, and the last is a check digit. Multiply the digits by 3, 7, 1, 3, 7, 1, 3, 7, 1, add the products, and the total must divide evenly by 10 (Apache Commons Validator documents the same weights).

Take the valid example number 021000021. The sum is 3(0+0+0) + 7(2+0+2) + 1(1+0+1) = 0 + 28 + 2 = 30, so it passes. If OCR reads the last 1 as 7, the sum becomes 36 and the number fails. We tried all 81 single-digit misreads of this number (9 positions times 9 wrong digits) in Python, and every one failed. Swapped neighbor digits are caught in most cases, but not when the two digits differ by exactly 5.

Amounts, dates and names have no check digit, so the $1,250.00 read as $7,250.00 earlier would pass a format check. For those, use reconciliation: line items sum to the subtotal, subtotal plus tax equals the total, running balances carry from row to row. Our guides to [invoice line-item extraction](/resources/blogs/invoice-line-item-ocr) and [data normalization for extracted documents](/resources/blogs/data-normalization-extracted-documents) cover those rules, and the [passport MRZ checksum guide](/resources/blogs/mrz-passport-verification) shows the same idea on identity documents.

## What should you expect from an OCR API?

Expect text with a confidence score for each word or field, published limits on file and text size, and worse results on poor input. Do not expect 100%. Expect to set a confidence threshold, send everything below it to review, and test on your own documents before you commit.

Amazon Textract returns confidence as a number from 0 to 100, and Azure's OCR service returns a value between 0 and 1 for each word. Both are the engine's own estimates, so Microsoft tells customers to scan a sample of their own content before choosing a threshold. Textract's guidance says archival uses might go as low as 50%, while business processes involving financial decisions might need 90% or higher.

| Published input limit | Amazon Textract | Azure Document Intelligence (Read) |
| --- | --- | --- |
| Minimum text height | 15 pixels (8-point at 150 DPI) | 12 pixels on a 1024 x 768 image (about 8-point at 150 DPI) |
| Quality advice | Ideally at least 150 DPI; do not downsample supported files | One clear photo or high-quality scan per document |
| Image size | 10,000 pixels or less on all sides | 50 x 50 to 10,000 x 10,000 pixels |

We read both pages on September 21, 2026. Limits change, so re-check them. If in doubt, 300 DPI clears every number here.

## What to do next

- Your files are digital PDFs: check for a text layer first and skip OCR if it is there.
- You scan or photograph documents yourself: apply steps 3 to 8 of the checklist.
- You are choosing a vendor: ask the five questions in the claims table, test 50 of your own documents, and start from the best OCR software 2026 guide. The free Which OCR selector shortlists engines for your document mix. DocsAPI is our product; qualified lenders can evaluate it with a free 30-day trial for qualified lenders after a demo.
- You use Tesseract or PaddleOCR: see PaddleOCR vs Tesseract vs DocsAPI.
- You handle handwriting, faxes or money fields: budget for review and add check digits, reconciliation and thresholds (see the handwritten invoice accuracy data).
- You are weighing AI vision models: read VLM vs OCR.

## Sources and how we checked this

Numbers described as ours come from the [OCR accuracy benchmark 2026](/resources/blogs/ocr-accuracy-benchmark-2026) (1,700 real, anonymized documents), quoted as published there. Everything else comes from these pages, opened on September 21, 2026.

- Amazon Textract quotas: text height, image limit, handwriting, languages.
- Amazon Textract best practices: 150 DPI, confidence thresholds.
- Microsoft Learn, OCR capabilities and limitations: word error rate, confidence values.
- Microsoft Learn, Document Intelligence Read model: text height, image size.
- Tesseract documentation, improving the quality of the output: 300 DPI, skew, borders, dictionaries.
- Rose Holley, How Good Can It Get?, D-Lib Magazine, 2009: accuracy scale, newspaper sample.
- U.S. National Archives, 1950 Census records: the accuracy statement.
- Apache Commons Validator, ABANumberCheckDigit: the routing number check.

Limits of this page. Our benchmark is one document mix, and yours will differ, so test your own files. The p^N table assumes independent errors, which real documents do not follow exactly. The probability table, edit-distance example and routing-number test were run in Python 3. We left out any claim we could not tie to a page we opened. DocsAPI is our product.

## Frequently Asked Questions

### What is a good OCR accuracy percentage?

There is no official cutoff. One scale used for digitized newspapers calls 98-99% good, 90-98% average and below 90% poor. For data extraction, judge by whole fields instead: at 99% per character, about 1 in 10 ten-digit account numbers still contains an error, and finance workflows usually need better than that.

### Is 95% OCR accuracy good enough?

It can be fine for searching a scanned archive, where a few misread characters rarely hide a page. For pulling out amounts, dates or IDs it is rarely enough. At 95% per character there are about 50 wrong characters per 1,000, and only 59.9% of 10-digit numbers would come out fully right (0.95 to the power of 10).

### Does a higher DPI always improve OCR accuracy?

No. DPI matters because it sets how many pixels make up each letter. The sources on this page point to 150 to 300 DPI as the range to aim for, and Tesseract suggests resizing anything below 300 DPI. A blurry, skewed or low-contrast image stays hard at any DPI, and upscaling cannot add detail that was never captured.

### Can AI or a vision-language model make OCR 100 percent accurate?

No. A vision-language model can understand meaning and adapt to odd layouts, but it costs more per page, can vary from run to run and still makes mistakes. Many teams use dedicated OCR for the bulk of pages and a model for the hard few. Our VLM vs OCR guide compares cost, speed and repeatability.

### Can running two OCR engines and comparing them reach 100 percent?

Not on its own. When two engines disagree on a field, that is a useful signal to send it for review. But when they agree, both can still be wrong, especially on look-alike characters such as 0 and O, so agreement lowers the error rate without removing it. Pair it with rules such as check digits and totals.

### Do I need to deskew images before sending them to an OCR API?

It depends on the engine. Amazon Textract's quotas page says it supports all in-plane document rotations, while Tesseract's documentation warns that heavy skew severely hurts its output. Read your engine's documentation, and test a deliberately tilted sample from your own documents before you decide to skip the step.

### Why is my Tesseract OCR not accurate?

Usually the input. Tesseract's documentation says it works best at 300 DPI or more and suffers from heavy skew, noise and large borders. On hard documents the engine itself is also weaker: in our benchmark Tesseract scored 58-71% on the four hard categories, against 73-89% for PaddleOCR. Clean typed English was a tie at 97-99%.

### Does language or script change OCR accuracy?

Yes. In our benchmark, pages mixing English with Mandarin or Spanish scored 71% on Tesseract, 89% on PaddleOCR and 81% on DocsAPI. Engines also list the languages they support: Amazon Textract text detection covers six, and its handwriting recognition is English only. Set the language to match the page and check support before you buy.

### How many documents should I test before trusting an OCR engine?

Our benchmark advice is 50 real documents from your own workflow, including the messy ones, scored against a hand-labeled answer key. It takes a few hours and predicts your results better than any published benchmark, including ours. Count errors per field, not just per character, and look at your worst documents separately.

### Is OCR accurate on photos taken with a phone?

Less than on flatbed scans. In our benchmark, phone-photographed receipts scored 58% on Tesseract, 82% on PaddleOCR and 76% on DocsAPI. The benchmark write-up says pre-processing such as deskew, rotation correction and page boundary detection closes most of that gap, so shoot flat, in even light, and crop before OCR.

### What is a good OCR accuracy rate?

For clean printed documents, 97 to 99% character accuracy is normal for modern engines in our benchmark. Judge the OCR accuracy rate at field level, though: with 20 fields per document and 99% accuracy per field, 1 minus 0.99 to the power of 20 means about 18% of documents have at least one wrong field.


---

**Source URL (cite this):** https://docsapi.co/resources/blogs/understanding-ocr-accuracy-metrics-challenges-and-improvement-strategies
**Author profile:** https://docsapi.co/author/nupura-ughade
**Published by:** DocsAPI (https://docsapi.co)