https://txtfetch.com/languages/arabic/
Extract text from Arabic documents, in the right order.
A born-digital Arabic file needs no OCR. The real risks are reading order, presentation-form glyphs, and the standard tier's OCR limit, not the script itself.
العربية · Arabic, right-to-left
what-already-works
A born-digital Arabic file, a Word document or a modern PDF with a real text layer, needs no OCR. Tika reads its Unicode text layer directly, in logical reading order, regardless of the right-to-left direction the text displays in.
character-encodings
| encoding | seen in | note |
|---|---|---|
Windows-1256 (CP1256) | Older Arabic Windows software, and legacy email or text exports. | A single-byte Arabic encoding. Read as UTF-8 or Latin-1 by mistake, every Arabic letter corrupts. |
common-pitfalls
- Arabic text extracts in the wrong order, reversed from how it reads.
- Some PDF producers store right-to-left text in visual order, the order the glyphs appear on screen, rather than logical order, the order a reader reads them in. This is a reading-order problem, not a missing-character one. Check the reading-order fix for how to detect and correct it. Fix columns and reading order →
- Arabic letters extract correctly but look like isolated, disconnected forms instead of their normal joined shape.
- Some old PDFs embed Arabic presentation forms, contextual glyph shapes from the Unicode U+FE70 block, instead of the base Arabic letters. Fold presentation-form characters back to their base Arabic letters before using the text for search or comparison.
- Vowel marks (tashkeel) above and below the letters are missing from the extracted text.
- Most everyday Arabic writing, print and digital, omits these marks entirely. Their absence is normal, not a defect. Treat unmarked Arabic as the expected form. Extraction can't add marks that were never in the source.
chunking-and-tokens
Arabic words are separated by spaces, so a word-count chunker splits Arabic text in roughly the right places. Presentation-form ligatures and the right-to-left layout don't change that word count, only the glyph shapes. The chunk previewer's ~4-characters-per-token estimate is a reasonable starting point for Arabic.
ocr-status
The standard OCR tier ships English trained data plus script detection only (TESSDATA_LANGS=eng osd). Latin-trained OCR data cannot read Arabic letterforms, since the shapes share almost nothing with the Latin alphabet. For any scanned or photographed Arabic document, request quality=premium, which routes a vision-language model instead of Tika. No accuracy figure is published for Arabic OCR under either tier. If Arabic scans are a large part of your workload, contact us before you commit to a plan.
faq
- Does txtfetch detect or label the document's language?
- No. txtfetch extracts the text as written and hands it back as-is. It does not detect, tag, or translate a document's language. There is no language parameter to set.
- Can txtfetch OCR a scanned Arabic document?
- Not reliably with the standard tier, which ships English trained data plus script detection only (TESSDATA_LANGS=eng osd). Request quality=premium for the documented route to reading an Arabic scan.
- Why does my Arabic text come out in the wrong order?
- Some PDF producers store right-to-left text in visual, on-screen order rather than logical reading order. This is a reading-order issue, addressed in the fix for columns and reading order.
- Why are the vowel marks missing from my extracted Arabic text?
- Most Arabic writing omits tashkeel vowel marks in the source document itself. Their absence in the extracted text reflects the source, not a loss during extraction.
related-reading
Check your Arabic scan first.
The free scan check tells you if a page needs OCR. It runs in your browser.
Check a scan →