YaiGlobalArabic OCR

YaiGlobal Parser vs Tesseract

Tesseract is the default because it is free and ubiquitous. On Arabic it records a 54.00% character error rate — and 75.75% on handwriting.

Tesseract is a genuinely important piece of software and the reason a great deal of Latin-script digitisation happened at all. On Arabic its architecture works against it: it assumes a character segmentation step that Arabic cursive script does not provide. This page gives the measured numbers and is explicit about the cases where Tesseract is still the right answer.

Measured side by side

Tesseract's figures are quoted from the published KITAB-Bench paper, produced by its authors — not measured by us.

Head to head on the KITAB-Bench tasks.
Task / measureYaiGlobalTesseractRelative gap
Image-to-text CER ↓12.50%54.00%−76.85%
Image-to-text WER ↓25.00%84.00%−70.24%
Image-to-text chrF ↑85.2339.62+115.12%
Handwriting CER ↓14.50%75.75%−80.86%
Handwriting WER ↓37.25%115.50%−67.75%
Table structure TEDS ↑ (via Img2Table)97.9938.64+153.60%
Table structure TEDS ↑ (via Docling)97.9928.23+247.11%

Tesseract places seventh of seventeen on image-to-text — above EasyOCR, PaddleOCR and several vision-language models, and below the three systems that cluster at the top. On handwriting its word error rate of 115.50% exceeds 100%, which means it emits more spurious content than there was reference text. See why error rates exceed 100%.

Why Arabic specifically is hard for Tesseract

This is architectural rather than a matter of tuning or training data.

Tesseract's recognition pipeline assumes that characters can be separated before they are identified. That assumption holds well for Latin print, where whitespace between glyphs is reliable. Arabic is cursive even when printed — letters join to their neighbours, and most letters take different shapes depending on position. There is no reliable segmentation boundary to find.

The consequence shows up most sharply on handwriting, where joins are irregular and baselines drift. Tesseract degrades from 54.00% to 75.75% CER; the parser moves from 12.50% to 14.50%. More on why Arabic is harder →

Tesseract in a pipeline does not fix structure

A common approach is to pair Tesseract with a downstream layout or table framework. The measurements show the downstream choice matters — and that neither rescues the result:

Table structure recognition, TEDS. Higher is better.
PipelineTEDS ↑
YaiGlobal Parser97.99
LlamaParse90.55
Surya + Marker50.15
EasyOCR + Docling49.10
EasyOCR + Img2Table39.09
Tesseract + Img2Table38.64
Tesseract + Docling28.23

Worth noting for anyone assembling a pipeline: the same EasyOCR output scores 49.10 through Docling and 39.09 through Img2Table. Table fidelity is a property of the whole chain, not of the OCR engine alone — so a pipeline can be improved by changing the downstream stage, just not enough to close a gap of this size.

When Tesseract is still the right choice

These are real cases and we would rather name them than pretend they do not exist.

  • Zero budget. Tesseract is free and Apache-licensed. If there is no budget, the comparison is not between two systems; it is between Tesseract and nothing, and Tesseract wins that.
  • Clean modern printed Arabic feeding a fuzzy search index. If the output is used for approximate full-text matching rather than as a record, a high character error rate degrades recall without making the system useless.
  • Fully offline with no procurement path. It runs anywhere, with no licence, no API and no vendor relationship.
  • Latin-script or mixed corpora where Arabic is incidental. Tesseract's Latin performance is a different and much better story.
  • Prototyping and feasibility work, where the question is whether a pipeline can be built at all.

A calculation worth doing before dismissing the cost difference. At a 54.00% character error rate, roughly one character in two on printed Arabic needs correction. The relevant comparison is not licence cost against zero — it is licence cost against the human correction hours the error rate implies across your volume. For a small clean corpus that maths favours Tesseract. For a large or difficult one it usually does not, and the crossover is worth computing rather than assuming.

What this comparison does not establish

This evaluation was conducted by YaiGlobal. Tesseract's figures come from the published KITAB-Bench paper and were not re-run by us, so configuration differences — language data, page segmentation mode, pre-processing — are confounded with capability. A carefully tuned Tesseract deployment with good pre-processing may well outperform the benchmark configuration. No independent party has replicated the comparison.

It also covers four of the benchmark's nine tasks, and Tesseract does not attempt several of them.

Compare on your own documents

You almost certainly have Tesseract output already. Send us the same pages and we will run them and return the output alongside, so the comparison is on your material rather than someone else's benchmark.

Send a sample →   Read the methodology

Scope. Vendor-conducted evaluation on four of the nine KITAB-Bench tasks, 5,949 samples. Tesseract figures quoted from the published benchmark paper (Heakl et al., Findings of ACL 2025, arXiv:2502.14949), not re-run by YaiGlobal. Image-to-text aggregates are unweighted macro averages; the sample-weighted CER for YaiGlobal Parser is 14.08%. Tesseract is maintained as an open-source project under the Apache 2.0 licence. Full methodology and limitations.