OCR PDF engines are built around left-to-right text flow. When you feed them a document written in a right-to-left script such as Arabic, Hebrew, Persian, or Urdu, the engine must detect the script direction, recognize characters in the correct visual and logical order, and output text that reads naturally in the target language. Getting one of these steps wrong produces text that is technically recognized but functionally unusable: words spelled backward, sentences that start at the end, and numbers that appear on the wrong side of the surrounding text.
Correct OCR for right-to-left languages requires selecting an OCR engine that explicitly supports the target script, configuring it with the correct language parameter, and verifying the output through bidirectional text-aware tools. The process is not materially harder than OCR for left-to-right languages, but the configuration step that many users skip, telling the engine what language to expect, is not optional for right-to-left scripts. An engine left on its default settings, usually English, will produce nonsense output from an Arabic or Hebrew document.
WukongPDF's Scanned PDF OCR tools support multiple languages including right-to-left scripts. Selecting the correct language before running OCR is the difference between extracting usable text and generating character noise.
Why Right-to-Left OCR Fails Without Explicit Configuration
OCR engines analyze shapes and map them to characters in the specified language's character set. When the engine expects English, it interprets shapes as Latin letters. The Arabic letter for B looks somewhat similar to the Latin letter B in many fonts, but the Arabic letter for Ayn has no Latin equivalent. An engine in English mode encountering Ayn outputs a random punctuation mark or skips the character entirely. Across a full document, this character-by-character misrecognition produces output with no relationship to the original text.
Even when the correct script is selected, the text direction introduces a second layer of complexity. OCR engines process images left to right by default, moving across each row of pixels from the left edge to the right edge. A right-to-left document should be processed right to left so that the engine reads the characters in the order they were written. If the engine does not reverse its processing direction for right-to-left scripts, the recognized characters will be in reverse order within each word. Some engines handle direction reversal automatically when the language parameter is set. Others require an explicit text direction flag.
Configuring Tesseract for Right-to-Left OCR
Tesseract, the open-source OCR engine, supports Arabic, Hebrew, Persian, Urdu, and several other right-to-left scripts through language-specific data files. Install the language data for the target script. On Linux, the package is typically named tesseract-ocr-ara for Arabic or tesseract-ocr-heb for Hebrew. On Windows, download the trained data file from the Tesseract GitHub repository and place it in the tessdata directory.
Run Tesseract with the language flag set to the correct script: tesseract input.pdf output -l ara for Arabic, -l heb for Hebrew, or -l ara+eng for a bilingual Arabic-English document. Tesseract handles text direction automatically when the language parameter specifies a right-to-left script. The recognized text output preserves the correct reading order. To verify, open the output text file and confirm that words read in the expected direction and that sentences flow from right to left.
For documents with mixed scripts, such as an Arabic research paper that contains English technical terms, specify both languages separated by a plus sign: -l ara+eng. Tesseract switches between the language models on a per-word basis, applying the Arabic model to Arabic-script words and the English model to Latin-script words. The per-word switching is not perfect, particularly on short words that could belong to either script, but it handles the majority of mixed-script documents adequately.
Using Google Cloud Vision for Auto-Detection
Google Cloud Vision's OCR capabilities include automatic language detection, which is particularly useful for right-to-left scripts when you are not certain of the exact language or when the document contains multiple right-to-left languages. The API accepts a document image and returns recognized text with bounding boxes for each word, the detected language for each text block, and the text direction. For right-to-left scripts, the returned text is already in the correct reading order.
Cloud Vision's Arabic and Hebrew recognition quality is generally higher than Tesseract's because the underlying models have been trained on larger and more diverse datasets. The tradeoff is that the document image must be uploaded to Google's servers for processing, which may not be acceptable for sensitive or confidential documents. For publicly available documents or internal documents where cloud processing is approved, Cloud Vision provides the most accurate right-to-left OCR available without purchasing specialized desktop OCR software.
| Language | OCR Engine Support | Accuracy Notes |
|---|---|---|
| Arabic | Tesseract, Google Cloud Vision, ABBYY | Diacritic marks may be dropped, ligature handling varies |
| Hebrew | Tesseract, Google Cloud Vision, ABBYY | Nikud vowel points often lost during OCR |
| Persian/Urdu | Tesseract, Google Cloud Vision | Nastaliq script variants challenge most engines |
Verifying OCR Output for Right-to-Left Text
After OCR, open the recognized text in a text editor that supports bidirectional text rendering, such as Notepad++ with the bidirectional plugin enabled or Visual Studio Code with an RTL language pack installed. Standard text editors that assume left-to-right text may display right-to-left text correctly if the Unicode bidirectional algorithm is implemented, but punctuation marks at the ends of lines and the relative ordering of numbers within text are common failure points. A text editor with explicit bidirectional support shows the text as a native speaker would expect to read it.
Spot-check the output against the original scanned document at three levels: individual words, particularly those containing diacritic marks or ligatures; full sentences, confirming that the word order reads naturally in the target language; and numbers and dates, confirming they appear on the correct side of the surrounding text. A document where every word is recognized correctly but the word order is reversed within each sentence is as unusable for translation or search as a document where no words are recognized at all.
OCR for right-to-left languages is a solved technical problem when the correct language parameter is set. The single most important step is telling the engine what script to expect. Everything downstream from that decision, from recognition accuracy to reading order to mixed-script handling, depends on getting the language configuration right. With the language parameter configured and a bidirectional text editor open for verification, OCR for a right-to-left language document takes no more time or effort than OCR for any other language.
Post-OCR Translation of Right-to-Left Language Text
Once the text is accurately recognized, translating right-to-left language content requires a translation engine that handles bidirectional text correctly. Google Translate and DeepL both support Arabic, Hebrew, and Persian. Paste the recognized text into the translation interface and confirm that the source language is correctly identified. The translation engine detects the script direction and preserves it in the output. For documents where the translation will be reviewed by a native speaker, export both the original recognized text and the translated text side by side in a two-column table for efficient comparison.
Machine translation of right-to-left languages is generally less accurate than translation between left-to-right European languages because the training data for many right-to-left language pairs is smaller. For critical documents, have a native speaker review the translation before acting on its content. The OCR step produces accurate source text. The translation step adds a layer of interpretation. Treat the OCR output as ground truth about what the document says, and the machine translation as a guide to what it means, subject to verification.
Batch Processing Right-to-Left Language PDFs
When you have a folder of right-to-left language PDFs to OCR, Tesseract's command-line interface accepts batch input. A single shell command processes every PDF: for f in *.pdf; do tesseract $f ${f%.pdf} -l ara; done. The command loops through all PDFs, runs OCR with the Arabic model, and saves recognized text alongside each PDF with matching base filenames.
For mixed-language batches, use a language detection step before OCR. A Python script with the langdetect library samples the first page of text to predict the language. Based on the prediction, the script selects the appropriate Tesseract language parameter and runs OCR. Automated language detection eliminates manual sorting of PDFs by language before batch processing. Batch OCR for right-to-left languages transforms a tedious per-document process into a single command that completes in minutes regardless of how many documents are in the input folder.
OCR for right-to-left languages is not a special case that requires exotic tools. It requires the same tools as left-to-right OCR, configured with the correct language parameter. The configuration step that many users skip because they assume OCR defaults will work is the entire difference between usable extracted text and complete character noise. Set the language flag, run the OCR, verify the output in a bidirectional text editor, and the process is complete. OCR for right-to-left scripts rewards the user who takes the time to configure the language parameter correctly and verifies the output in a bidirectional text editor, producing accurate, usable text from documents that would otherwise remain inaccessible to anyone who does not read the source language.