Why Do Global OCR Tools Fail with Arabic Text? The Real Technical Reasons, and How Baseer Overcame Them

We attempted to copy content from a PDF file to utilize it in a project, only to be surprised by inverted letters, bizarre symbols, and erratic spacingin fact, the tables had completely vanished. When we resorted to an OCR tool to extract the text digitally, it succeeded in pulling the content, but tables were reduced to scattered, disjointed rows, and the word order was flipped upside down.

This was the experience of one of our clients, illustrating the critical importance of having an accurate OCR capable of transforming this document's content into digital text that is editable, indexable, and ready for automated processing. However, the majority of tools built for this purpose were not designed for Arabic. Most OCR tools were foundationalized for languages with disconnected letters written from left to right, relying on hundreds of millions of pages for training. The Arabic language, with all its visual and structural complexities, was often an afterthought rather than a primary objective. These tools "support" Arabic but were not built for it. Consequently, the overall performance is unsatisfactory, especially with files that have complex structures or poor quality (whether in text or embedded images), leading to a loss of document structure and a host of other issues.

This article explains the true technical reasons behind these failures and the necessity of building an OCR rooted in the Arabic language to serve it properly.

Before we can understand why these tools fail, we must understand what makes Arabic visually and structurally distinct from the languages for which most OCR systems were designed.

In English, the letter "A" is always "A," whether at the beginning, middle, or end of a word. This is not the case in Arabic.

A single Arabic letter takes up to four different shapes depending on its position in the word: one shape at the beginning, another in the middle, a third at the end, and a fourth if it stands alone. Specialized OCR studies indicate that the Arabic writing system contains no less than 81 distinct letter shapes in total.

The shape of the letter "ب" (Ba) in "بدر" (Badr) differs from the "برب" (Arab) and the "ب" in "كثب" (Kutub)three positions, three shapes. An OCR algorithm not trained on this sees three different letters, not one. !

Source: Contour-based character segmentation for printed Arabic text with diacritics

English and other Latin languages are written with separate letters, even if they appear connected in certain fonts. However, a primary visual characteristic of Arabic is its cursive flow. A word like "مستخفى" (hospital), which consists of six letters, appears to the algorithm as a single, continuous visual band with no breaks. In contrast, for the English counterpart "hospital," the system sees eight visually independent letters from the outset. This makes "segmentation" the fundamental step in traditional OCR systems vastly more difficult, as the algorithm attempts to locate letter boundaries within a continuous text band rather than at clear separation points. !

Source: Novel deep convolutional neural network-based contextual recognition of Arabic handwritten scripts

Many Arabic letters share the same base shape and differ only in the number and position of dots: (ي), (ن), (ن) , and five different letters sharing a single base form, distinguished solely by dots.

Furthermore, diacritics (Fatha, Damma, Kasra, Tanween, and Sukoon) carry crucial semantic differences. The word "بَيْنٌ" (house) is fundamentally different from "بَيَّتْ" (to harbor/plot). When OCR tools ignore diacritics or convert them into strange symbols, the meaning changes, often rendering the text incomprehensible and unusable in many contexts.

In a comprehensive research review published in MDPI Applied Sciences, diacritics and cursive connectivity were ranked among the greatest challenges facing OCR systems when processing Arabic text.

(c) !

(d) !

Source: Contour-based character segmentation for printed Arabic text with diacritics

Arabic is written from right to left (RTL). However, numbers within Arabic text are written from left to right (LTR). This alternation between directions is known as bidirectional text.

OCR systems originally designed to process text from left to right (LTR) output this text inverted resulting in reversed dates, misplaced numbers, and disrupted word order.

The task becomes exponentially more complex when a single line contains a mix of Arabic and English words (such as technical terms or foreign names). Since Arabic is written from the right and English from the left, OCR algorithms not designed for this intersection completely lose their "compass." They begin reading the English word from the end or insert it in the wrong place within the sentence, turning the text into chaos. This corrupts the meaning, disrupts the flow of the text, and makes indexing and automated searching within digital documents nearly impossible.

The Arabic language is incredibly rich in its typographic and calligraphic diversity, unmatched by most other languages. What appears to a human reader as a variation in aesthetic style represents a sharp, barely recognizable contrast to a poorly trained OCR algorithm.

This multiplicity poses a dual challenge. Fluid calligraphic scripts like Diwani and Thuluth rely on vertical stacking (letters on top of letters), which confuses scanning systems searching for a straight horizontal path. Meanwhile, modern fonts often feature geometric simplifications that may erase traditional features upon which older models were trained. The lack of visual standardization in Arabic typography makes it impossible for a tool not built specifically for this environment to understand that a stylized "Meem" is the exact same letter as a "Meem" printed in a textbook. This ultimately leads to a collapse in recognition accuracy at the slightest change in font style.

Even assuming an OCR tool recognizes Arabic letters reasonably well, a fundamental problem remains: understanding the page layout.

Traditional OCR models treat a document as a set of text lines ordered from top to bottom. Real documents, however, are not structured this way: they contain tables with cells, rows, and columns; headings of various sizes; numbered and bulleted lists; footnotes; and multi-column elements.

When a line-by-line OCR tool reads this type of document, the output is a single, long, distorted paragraph table data is jumbled, and the order of information is inverted.

In an Arabic document, the layout carries legal, academic, and professional meaning. A lease agreement table contains: Name of First Party, Name of Second Party, Rent Amount, Start Date, End Date. If the cells of this table disintegrate and their data mixes, the document becomes legally unusable even dangerous.

Researchers on the REJD (Real Estate and Judicial Documents) dataset project, published in the MDPI Electronics journal in 2025, emphasized that governments need to digitize official documents like property records and court decisions, and that the failure of layout analysis represents the primary obstacle.

Source: MDPI Electronics, Toward Building a Domain-Based Dataset for Arabic Handwritten Text Recognition, 2025

Documents are often of sub-optimal quality; especially those scanned with mobile phones, suffering from poor lighting, faded ink, or visual "noise" from paper folds. This causes most

OCR tools to lose their accuracy the moment image quality drops, due to their reliance on Pattern Matching, which requires highly distinct edges.

The greatest challenge in Arabic, however, is "character erosion." When the dot of a "Qaf" (ق) fades, or a "Seen" (س) bleeds into the following letter due to a poor scan, current OCR tools completely lose their ability to distinguish the characters. This clearly highlights the importance of highly robust systems that read and understand the letter within its linguistic and visual context to compensate for poor page quality.

Example of poor image resolution resulting from photography

Training a highly accurate OCR model requires massive amounts of data: images of documents containing text alongside the corresponding correct ground-truth text. The gap between English and Arabic in this regard is vast.

This gap means that models like Tesseract which is open-source and widely used rely on less dense and less diverse Arabic training data. Tech communities like Reddit's r/OCR and r/computervision are filled with complaints about Tesseract's subpar performance with Arabic, often recommending EasyOCR as a relatively better alternative. Yet, even this alternative struggles with tables and complex layouts. "We tried Tesseract for Arabic... the results are frustrating even with all the preprocessing. EasyOCR is slightly better, but tables are completely lost." Reddit r/computervision discussion.

Even the most popular tools backed by tech giants are not exempt from these issues when it comes to Arabic text:

• ### Tesseract: The Most Used, But Not for Arabic

Tesseract is open-source, free, and fast. However, it was fundamentally designed to process clean printed text with clear fonts. It relies on traditional segmentation and classification stagesprecisely the stages that fail with cursive writing. In documented practical tests across various tech forums, users of Tesseract for Arabic required extensive preprocessing layers (lighting enhancement, skew correction, contrast improvement) just to get near-acceptable results. Even then, accuracy on tables and intertwined fonts remains poor.

• ### Adobe Acrobat: Good for English, Average for Arabic

Adobe Acrobat Pro includes an advanced OCR engine that works well with Latin texts. However, user reviews for Arabic texts indicate average accuracy, particularly with non-standard fonts or older documents. Furthermore, table extraction in Arabic documents is a documented weak point, and it does not provide a flexible API for developers.

• ### Google Document AI & Microsoft Azure Document Intelligence

These cloud tools clearly outperform Tesseract in general accuracy and support Arabic within their language lists. But being built on multilingual models means Arabic is a "supported language," not an "optimized language." Their costs are high at scale ($1.5 per thousand pages for basic text, jumping significantly for tables and structure), and routing documents through external servers raises genuine privacy concerns for sensitive documents.

• ### Mistral OCR

Mistral OCR represents the latest generation of document understanding tools launched by Mistral AI, relying on a "Vision Model" architecture capable of reading the document as an integrated visual block encompassing text, images, and complex mathematical equations simultaneously. Despite its notable superiority in global performance benchmarks and its ability to extract content in structured Markdown, it remains a "global" model designed to serve thousands of languages and writing systems. This means that the specificities of Arabic with its complex cursive connectivity, diverse shapes, and overlapping dots remain within the scope of general support, not at the core of fundamental optimization.

The Arabic user still faces challenges with it, such as its inability to support complex Arabic structures, occasional text repetition and clear hallucination in certain sections, and a breakdown in precise diacritic alignment or maintaining the correct RTL/LTR direction in more complex tables. This often necessitates human review to guarantee complete linguistic and structural accuracy.

Source: E2E Networks OCR Guide 2025 - Comparison of OCR Tool Costs and Performance

All the problems we reviewed stem from one flawed assumption: that a model trained on English can be "adapted" to work with Arabic. Baseer, however, originates from a model trained on multiple languages, featuring Arabic and English as primary languages.

Built on Real Arabic Data

Baseer is a Vision-Language Model (VLM) developed by Misraj AI, built on Qwen2.5 VL 3B and rigorously fine-tuned (SFT) on 769,000 pages of Arabic documents. These pages include academic books, government documents, commercial invoices, magazines, and research papers with a diversity of fonts, sizes, and image qualities that reflect actual real-world usage.

Baseer outperforms Gemini 2.5 Pro, GPT-4o, and Azure Document Intelligence on the Misraj DocOCR benchmark and evaluation standard comprising 400 manually reviewed, diverse Arabic documents.

Reads the Page as a Full Image, Not as Lines

What distinguishes Baseer as a Vision-Language Model is that it was created specifically for the Arabic language, trained on appropriate and diverse data, and treats the document as a comprehensive image it understands visually and contextually not as a sequence of lines. This means it understands table architectures and preserves their layouts, distinguishes headings from paragraphs, respects the text hierarchy, and converts all of this into structured Markdown that reflects the original document's architecture. This produces content ready for immediate use in research, systems, and applications.

Source: Misraj DocOCR Benchmark - 400 diverse, manually reviewed Arabic documents. Misraj AI, 2026

The failure of OCR tools with Arabic text is not a technical glitch that can be solved by tweaking settings; it is the natural consequence of tools built for a different purpose. The core reasons can be summarized as follows:

• 81 letter shapes in the Arabic writing system, general tools do not cover them.
• Cursive writing makes segmentation significantly harder.
• Diacritics and dots are ignored or turned into meaningless symbols.
• Bidirectional (RTL/LTR) orientation flips the order of words and numbers.
• Font diversity (Ruq'ah, Diwani, Naskh, Kufi) exceeds the capabilities of general models.
• Layout analysis failure turns tables into unusable textual chaos.
• Scarcity of Arabic training data compared to English.

Ultimately, Baseer emerges from its own language, not from the languages of others.

1. Salaheldin Kasem, M., Mahmoud, M., & Kang, H. S. (2025). Advancements and challenges in Arabic optical character recognition: A comprehensive survey. ACM Computing Surveys, 58(4), 1-37.
2. Faizullah, S., Ayub, M. S., Hussain, S., & Khan, M. A. (2023). A survey of OCR in Arabic language: applications, techniques, and challenges. Applied Sciences, 13(7), 4584.
3. Faizullah, S., Ayub, M. S., Alghamdi, T., Ali, T. S., Khan, M. A., & Nabil, E. (2024). Revolutionizing Historical Document Digitization: LSTM-Enhanced OCR for Arabic Handwritten Manuscripts. International Journal of Advanced Computer Science & Applications, 15(10).
4. Alhefdhi, K., Alsalman, A., & Faizullah, S. (2025). Toward Building a Domain-Based Dataset for Arabic Handwritten Text Recognition. Electronics, 14(12), 2461.
5. Ahmed, R., Gogate, M., Tahir, A., Dashtipour, K., Al-Tamimi, B., Hawalah, A., ... & Hussain, A. (2021). Novel deep convolutional neural network-based contextual recognition of Arabic handwritten scripts. Entropy, 23(3), 340.
6. Mohammad, K., Qaroush, A., Ayesh, M., Washha, M., Alsadeh, A., & Agaian, S. (2019). Contour-based character segmentation for printed Arabic text with diacritics. Journal of Electronic Imaging, 28(4), 043030-043030.
7. Flitto DataLab. Arabic Text Recognition: Challenges and Solutions, 2024.
8. Encyclopedia MDPI. Arabic Optical Character Recognition Challenges, 2023.
9. E2E Networks. Complete Guide to Open Source OCR Models, 2025.
10. Reddit r/OCR, r/computervision. User discussions on Arabic OCR (Documented experiences).
11. Misraj AI. Baseer: The Vision-Language Model from Misraj for Arabic Document Understanding, 2026.
12. Misraj DocOCR Benchmark. 400 diverse, manually reviewed Arabic documents.