Tesseract.js OCR accuracy test: 10 languages compared

Short answer. CreatorPrivacyKit Local OCR now ships eleven Tesseract language packs and lazy-loads them after you click Run OCR. That does not mean every language reads photographed documents well. On this 2026-09 engine benchmark, 1 of 10 fixtures passed (≥95% key fields), English was a warn, and eight failed — including Simplified Chinese, Japanese, Hindi and Arabic.

Benchmark setup

We scored the production engine: Tesseract.js 5.1.1, LSTM tessdata 4.0.0_best_int, OEM 1, page segmentation mode 6. No cloud OCR. No fixture-specific crops, regexes or post-processing.

These are synthetic-but-controlled document scenes we built for repeatable testing. They are not a third-party academic dataset, not an industry benchmark, and not real customer invoices or hospital records. Decorative extras on the photos (mugs, adjacent posters, glass reflections) are not in the scored ground truth.

Interactive laboratory hub: 2026 OCR Benchmark Hub · Detailed Results & Failure Analysis · Full Methodology · Download Raw Datasets (JSON & CSV).

The 10 test images

Each sample has a public ID. Captions below use that ID.

Overall results

Engine benchmark on this host (Node v22, Linux x64). Lower CER is better. Key-field accuracy is exact substring match, not “looks similar”.

PASS is ≥95% key fields; WARN is 85–95%; FAIL is below 85%. Mean key-field accuracy across the ten scored fixtures: 54.1%. Mean numeric exact: 60.8%. Mean email exact: 40%. Mean URL exact: 60%.

English OCR

OCR-EN-2026-001 is a desk photo of a printed invoice. The engine got Invoice No, date, address, email, phone, line items, tax rate, and $145.06. It missed the large stylized word “INVOICE” (15/16 key fields → 93.8%, WARN).

Chinese OCR

OCR-ZH-2026-002 is a wall notice with perspective. The document ID survived. Dates and the URL did not match exactly because Tesseract inserted spaces and broke the email:

Expected:
support@example.cn
https://example.cn/notice

Recognized:
support@example:cn
htips:J/examplecnne

Key fields: 18.2%. That is a fail even though some Chinese body words are readable.

Japanese OCR

OCR-JA-2026-003 is a photographed ramen menu. Email and URL matched. Menu prices did not: 1,080円 came out as 1.080, and 醤油 was read as 普油. Key fields: 27.8%.

Korean OCR

OCR-KO-2026-004 is a cafe poster on glass. Hangul body and several prices survived. The ID became 008-0-2026-004 instead of OCR-KO-2026-004, and the Latin email/URL collapsed. Shipping the kor pack is necessary; it is not sufficient for this photograph.

Spanish OCR

OCR-ES-2026-005 is a wrinkled receipt. The store name, ticket ID, date and URL matched. The phone lost spacing and a digit (+34 91 555 24 80 → +34 91555 24 60). Several euro amounts missed exact match because of the crumpled thermal print.

French OCR

OCR-FR-2026-006 is a decorative flyer. 10/12 key fields matched, including email and URL. The phone 04 72 55 18 90 did not. 83.3% is a fail on the 95% bar.

German OCR

OCR-DE-2026-007 is a clean clipboard product sheet. Every scored field matched, including Geräteübersicht, Lindenstraße, umlauts, 1,35 kg, serial MSP12-DE-884209, email and URL. This is the only PASS in the set. It is a printed, high-contrast sheet — not a poster behind glass.

Portuguese OCR

OCR-PTBR-2026-008 is a shipping label on cardboard. The title and several address fields matched. The document ID and the long email did not. 70% key fields.

Hindi OCR

OCR-HI-2026-009 is a Devanagari public notice with mixed Latin digits. The engine produced some Hindi, but the ID, date, phone, email and URL missed exact match. Key fields: 22.2%.

Arabic OCR

OCR-AR-2026-010 is two documents in one photo (clinic sheet + appointment card), RTL mixed with Latin email/URL/phone. The ara pack did run — Arabic letters appear — but none of the 11 scored fields matched exactly. Title became roughly “مركز النور لطبي” instead of “مركز النور الطبي”. Email and URL were lost. Key fields: 0%.

The result editor uses dir="auto" and unicode-bidi: plaintext so we do not force the whole textarea to RTL (that would scramble info@alnourmed.sa). Copy still uses Unicode logical order. Rendering of mixed Arabic+Latin remains a follow-up; this run is about recognition, not typesetting.

Numbers, URLs and email accuracy

Across ten fixtures: numeric exact 60.8%, email exact 40%, URL exact 60%. A low CER can still hide a one-digit price error. That is why we score those fields separately. English and German got money, email and URL exact on these images. Chinese, Korean, Hindi and Arabic did not.

Where browser OCR struggled

• Photographed posters, menus and glass (JA, KO, ZH, HI, AR).
• Stylized display type (English “INVOICE”).
• Wrinkled thermal receipts (ES amounts and phone).
• RTL plus Latin identifiers on a two-document desk scene (AR).
• Comma vs period in Japanese prices (1,080 vs 1.080).

Clean, high-contrast printed sheets (DE) are a different job from a menu board with photos.

What this benchmark does not prove

It does not prove accuracy on your documents. It does not compare Tesseract to Google Vision or Apple Live Text. It does not measure handwriting, vertical Japanese, or scanned PDFs (those have a separate native-text path). It does not mean “multilingual OCR” is uniformly good just because the language dropdown lists eleven packs.

How to reproduce the test

1. Fixtures: tests/fixtures/ocr-multilingual/
2. Ground truth: manifest.json (ground_truth_verified: true)
3. Engine: npm run benchmark:ocr -- --engine
4. Product UI path: npm run benchmark:ocr -- --e2e
5. Do not paste expected text into the OCR output. Normalization is NFC, newlines and spaces only.