Is Tesseract accurate enough for production?

Tesseract is accurate enough for production when your documents look like the ones it was built for, clean printed pages at a sufficient resolution, and your check on your own files says so. It does not publish an accuracy figure, so nobody can answer the question for you, and the useful move is to measure it on a sample of your own documents before you commit.

This page covers what Tesseract says about itself, what independent tests found, the conditions that make it fail, and a short test you can run in an afternoon with a go or no-go threshold set in advance.

What Tesseract says about itself

Tesseract is an open-source OCR engine under the Apache 2.0 licence. It supports more than 100 languages and uses an LSTM-based engine. Its README gives no accuracy number. It says that to get better results you will often need to improve the quality of the image.

Its documentation on improving quality is specific about when accuracy drops:

• Resolution. It works best on images of at least 300 DPI.
• Binarisation. Its default method can be suboptimal when the page background is unevenly dark.
• Skew. Line segmentation quality falls significantly if the page is too skewed.
• Noise. Noise that binarisation cannot remove can cause accuracy to drop, and dark scan borders can be read as characters.
• Tables. The documentation says it has a problem recognising text and data from tables without custom preprocessing.

Its FAQ says of handwriting that you can try, but it will not work very well, because Tesseract is designed for printed text.

What independent tests found

Few independent comparisons exist, and each has caveats.

A peer-reviewed benchmark by Hegghammer, published in the Journal of Computational Social Science in 2021 (DOI 10.1007/s42001-021-00149-1), compared Tesseract, Amazon Textract and Google Document AI on scans of English books and Arabic articles, with artificial noise added. It found the two cloud services substantially better than Tesseract, especially on noisy documents. The data are book and article scans from 2021, not invoices.

A vendor-run benchmark on receipts, published by ImageToTable and last reviewed on 18 August 2026, reports character error rates of 0.3347 for Tesseract on CPU, 0.2833 for EasyOCR and 0.2045 for PaddleOCR on the SROIE and CORD receipt datasets. It is run by a vendor, which says so, and it does not state the Tesseract version or preprocessing, so read it as one data point.

Neither result is yours. The same engine can do very well on clean scans and badly on skewed phone photos, which is why the test below matters more than any published figure.

When Tesseract works and when it breaks

It tends to work on clean, upright, printed text at 300 DPI or more with a plain background, such as a modern scanned letter or a typed form. It tends to break on skewed or low-resolution images, uneven backgrounds, noisy scans, tables, and handwriting. Layout analysis is a segmentation step you tune through its page segmentation modes, which range from 0 to 13, so results can change a lot with one setting.

Test it on 50 of your own documents

Pick 50 documents that cover your real mix: the best, the median and the worst scans you receive. Hand-label the fields you care about, such as invoice number, date and total, rather than the full text. Run Tesseract on all 50 with the same preprocessing, then score the results. Decide the pass threshold before you run it, so that the result does not shape the target.

Two measures cover most needs: the character error rate for free text, and an exact match for numbers, dates and identifiers.

def edit_distance(a: str, b: str) -> int:
    prev = list(range(len(b) + 1))
    for i, ca in enumerate(a, start=1):
        cur = [i]
        for j, cb in enumerate(b, start=1):
            cur.append(min(prev[j] + 1, cur[j - 1] + 1, prev[j - 1] + (ca != cb)))
        prev = cur
    return prev[-1]
 
def cer(expected: str, got: str) -> float:
    return edit_distance(expected, got) / max(len(expected), 1)
 
def field_matches(expected: dict[str, str], got: dict[str, str]) -> dict[str, bool]:
    return {k: got.get(k, "").strip() == v.strip() for k, v in expected.items()}

Report the results per document type and count the documents with any wrong critical field, because one wrong total can matter more than a hundred slightly noisy words. Fifty documents give a rough signal, not a guarantee, and a result from a small sample does not replace monitoring on production traffic.

A go or no-go checklist

• The critical fields pass your threshold on the documents you actually receive, including the worst quarter.
• Pages arrive at 300 DPI or you control the scanning, and you handle skew and background before OCR.
• You do not depend on tables or handwriting, or you have a separate answer for them.
• Someone owns preprocessing, upgrades and monitoring, which a managed service would otherwise carry.
• A wrong value has a cost you can tolerate, or a check or review step catches it.

If the answers are mostly no, you have the options of better preprocessing, a different open-source engine, a managed OCR API or a document processing platform that returns typed fields with confidence. How the cost compares is covered in OCR API vs open source.

Where anyformat fits

anyformat is a document extraction platform that sits at the end of that list. It returns typed fields with a confidence score and the source text and page they came from, so a person reviews the uncertain ones. It is not a substitute for the test above: run the same 50 documents through any option you consider, ours included. For the metrics that matter once documents reach production, see beyond accuracy.

Frequently asked questions