How to check that a searchable Arabic PDF really works

A searchable PDF is a page image with an invisible layer of text behind it. You see the scan; search, copy and screen readers use the hidden text. For Arabic, that hidden layer can fail quietly. The page looks perfect, the file is labelled "OCR'd", and yet searching for a word you can see returns nothing, or a copied line comes out backwards or in disconnected letters.

This guide is for anyone who has to sign off on Arabic PDFs before they are relied on: an editor or researcher building a library of digitized source books, a publisher putting a backlist online, or a records or document-service team delivering scanned files that a client expects to search. If you still need to make the PDF searchable, our answer page on making an Arabic PDF searchable and the Arabic OCR page cover that. This article is about checking a file you already have.

What "works" means for an Arabic text layer

Three things have to be true at once:

1. Every page has text. One image-only page in the middle of a book makes that page unsearchable, and nothing warns you.
2. The text is standard Arabic letters. Unicode has two ways to store Arabic: the normal letters (the U+0600 block) and "presentation forms" (U+FB50–U+FDFF and U+FE70–U+FEFF), which encode each letter's initial, medial, final or isolated shape as a separate character. They look the same on screen, but a search for ordinary typed Arabic does not match them.
3. The text is in logical order. Unicode stores right-to-left text in the order it is typed, and the display order is worked out afterwards (see the Unicode bidi FAQ). Some PDF generators write the letters in the order they appear left to right on the page. A viewer that does not rebuild the order then hands out reversed words.

Test 1: search for a word you can see

Pick three words from different pages, preferably ones with ta marbuta, hamza or lam-alif, because those break most often. Type them yourself into the search box of the viewer your readers actually use (Acrobat, a browser, a library platform), rather than copying them from the PDF. A word copied from a faulty layer will happily find itself.

Test 2: copy a line into a plain-text editor

Select one full line and paste it into Notepad, TextEdit or any plain-text editor rather than Word, so you see the characters as they come out of the PDF. Read it against the scan. You are looking for words in the wrong order, letters that no longer join, or digits that moved.

Do this in more than one viewer if your readers use more than one. In our test (below), two widely used open-source extractors gave different results on the very same file.

Test 3: check every page has text

Searching a few words does not find a missing page. Extract the text per page and look for pages with no Arabic at all. Poppler's pdftotext (free, on Linux, macOS and Windows) writes a form-feed character between pages, so you can split its output page by page. The script below does that.

Test 4: look at the fonts

pdffonts file.pdf lists every font in the file. The uni column says whether the font has a "ToUnicode" map, the table that turns drawn glyphs back into characters. A font with no in that column is worth a closer look, though the Poppler manual notes that a missing map does not always mean the text cannot be extracted. Image-only pages show no fonts at all.

Test 5: run the per-page script

This Python script uses pdftotext and checks each page for missing Arabic, presentation-form characters and signs of reversed text, then searches for any words you give it. You can also point it at a .txt file holding text you copied out of another viewer.

"""Usage: python3 check_arabic_pdf.py FILE.pdf|FILE.txt [word ...]
Needs pdftotext (Poppler) for PDFs. A .txt file is checked as one "page"."""
import re, subprocess, sys

BIDI = re.compile("[‎‏‪-‮⁦-⁩]")
ARABIC = re.compile("[ؠ-ي٠-٩ٱ-ۓ۰-۹]")
PRES = re.compile("[ﭐ-﷿ﹰ-]")
COMMON = ["في", "من", "على", "إلى", "عن", "التي", "الذي", "هذا"]

def pages(path):
    if path.lower().endswith(".txt"):
        return [open(path, encoding="utf-8").read()]
    out = subprocess.run(["pdftotext", "-enc", "UTF-8", path, "-"],
                         capture_output=True, text=True, check=True).stdout
    return out.split("\f")[:-1] or [out]

def words(text):
    return re.findall(r"[^\s\.,:;،؛؟!()\[\]«»]+", text)

path, wanted = sys.argv[1], sys.argv[2:]
all_text = ""
for n, raw in enumerate(pages(path), 1):
    text = BIDI.sub("", raw)
    all_text += text
    w = words(text)
    ar, pres = len(ARABIC.findall(text)), len(PRES.findall(text))
    fwd = sum(x in COMMON for x in w)
    back = sum(x[::-1] in COMMON for x in w)
    flags = []
    if ar + pres == 0:
        flags.append("NO ARABIC TEXT (image-only page?)")
    if pres:
        flags.append(f"{pres} presentation-form characters")
    if back > fwd:
        flags.append(f"LIKELY REVERSED ({back} reversed vs {fwd} normal common words)")
    print(f"page {n}: {ar} Arabic letters, {len(w)} words: " + ("; ".join(flags) or "ok"))
for word in wanted:
    print(f"search '{word}': {'found' if word in all_text else 'NOT FOUND'}")

The script strips the invisible direction marks that pdftotext adds around right-to-left lines before it counts anything. The "reversed" check is a rough signal: it counts how often very common short words (في، من، على) appear forwards or backwards.

What we tested, and what it showed

We ran this check on 29 October 2026, on six one-page PDFs built for the test from the same Arabic paragraph, printed to PDF with headless Chromium, and searched each for الكتاب and الطالب:

File	How it was built	pdftotext (Poppler 24.02)	Script result
A	Normal Arabic text	Clean, logical order	ok; both words found
B	Page image only	Nothing	NO ARABIC TEXT
C	Text typed as presentation forms	Looks right, wrong characters	presentation forms; words NOT FOUND
D	Presentation forms written in visual order	Words reordered, lines swapped	presentation forms; words NOT FOUND
E	Page image plus an invisible text layer	Clean, logical order	ok; both words found
F	Normal letters written in visual order	pdftotext rebuilt the order; lines swapped	ok; both words found

Two results are worth knowing. First, pdftotext rebuilds reading order from where letters sit on the page, so on file F it hid a problem that a simpler viewer would show. Its line order was still wrong, which a search for a single word does not catch. Second, we extracted file A with Mozilla's PDF.js library (version 4.10, the getTextContent call) and got mostly presentation-form glyphs in visual order. Fed that text, the script flagged presentation forms and neither word was found. We did not test the search box inside Firefox, Chrome or Acrobat, which may normalise text further. The point stands: a file can be searchable in one tool and not in another, so test where your readers will search.

We did not test any ScribeTools output in this run.

Checklist before you deliver or archive

• Three words, typed by hand, are found in the viewer your readers use
• A pasted line reads correctly in a plain-text editor
• Every page has Arabic text (no image-only pages)
• No presentation-form characters in the extracted text
• No "likely reversed" pages
• Fonts list a ToUnicode map, or extraction has been checked by hand
• Line order is right on a page with two or more lines (search alone misses this)
• Tashkeel, if the source has it, is either kept or deliberately removed, not half of each

Illustrative example

A research group receives a 400-page scanned commentary labelled "searchable". The script reports text on every page except pages 212 to 215, which turn out to be fold-out tables scanned separately and inserted without OCR. Pages 1 to 8, the publisher's front matter, show presentation forms, because they came from a different PDF generator. The body text passes. The fix is to run OCR again on just those twelve pages and replace them, not to redo the book.

When the layer fails

If text is missing or uses presentation forms, fixing it in a PDF editor is rarely worth the time. Run the affected pages through OCR that writes standard Arabic Unicode in logical order, and output a searchable PDF again. ScribeTools can produce a searchable PDF, editable Word and plain text from the same scan, which also helps when you need the text for Word: see digitizing Arabic books. If the problem shows up after you convert the PDF to Word, our guide to reversed Arabic text in Word covers the same three causes from the Word side, and Arabic search not finding words covers hamza, tashkeel and look-alike letters that also stop matches.

Limitations

• The script reads text the way Poppler extracts it. Other viewers can extract the same file differently, so it does not replace Tests 1 and 2.
• The reversed-text check relies on common short words and can miss pages with very little running text, such as tables or title pages.
• It does not check whether the recognised text is correct, only whether it is usable. A layer can be clean Unicode and still contain misread letters, so proofreading against the scan still matters.
• Our test files were built for the purpose and are single pages. Real scanned books, with footnotes, marginal notes and two columns, raise reading-order problems this check does not measure.