Arabic and Hebrew resumes: what ATS text extraction gets back

What we tested

We wrote 14 lines a bilingual resume might contain: nine in Arabic, four in Hebrew and one English line with an Arabic name inside it. They include headings, a job title, skills written in English inside an Arabic sentence, year ranges, a phone number, an email address and a percentage. Each line is set in Arial.

Each set went through two common ways of making a PDF: Chromium's print to PDF, the engine behind Chrome's Save as PDF, and LibreOffice Writer's PDF export from a DOCX. We also kept the DOCX itself, and made a third PDF by deleting the ToUnicode maps from the Chromium file. Then three PDF readers read each file back: pdf.js, Poppler's pdftotext and MuPDF.

A line counts as exact only when every character comes back in the order it was written. Text that is correct but wrapped in invisible direction marks is counted separately. Anything else is a change.

Why the file format matters: reading order and drawing order

Unicode stores right-to-left text in logical order: the order it is typed and read. The Unicode Bidirectional Algorithm (UAX #9) is what turns that into the order it is drawn on screen, right to left for Arabic and Hebrew and left to right for any English words or numbers inside them.

A DOCX keeps the logical order. Our 13 right-to-left paragraphs were stored as plain text in reading order, each flagged as right-to-left, and reading the XML back gave all 14 lines exactly.

A PDF keeps neither order as such. It stores glyphs and the positions to draw them at. A reader rebuilds lines from those positions and decides for itself which way each run reads. The two PDF producers stored the same lines differently, and the three readers rebuilt them differently, which is why the rows in the table above disagree so much.

The clearest gap is pdf.js. On the LibreOffice PDF it returned 10 of 14 lines exactly. On the Chromium PDF it returned 1. Same text, same font, same reader.

Mixed lines: English words and numbers move

Lines in a single script mostly survived. Across the six PDF reads, the three pure lines without lam-alef came back intact 16 times out of 18 (89%). The mixed lines came back intact 8 times out of 60 (13%).

The usual failure is that the English or numeric run moves to the front of the line. In the line below, the skills Python and SQL end the Arabic sentence. Two readers of the Chromium PDF put them first, and pdftotext kept the order but wrapped each run in invisible direction marks.

Dates and phone numbers

Year ranges came back reversed in several reads. “شركة النخيل للتقنية، 2019 – 2023” came back from the Chromium PDF with the years as “2023 – 2019” in every reader. Arabic-Indic digits fared worse: MuPDF reversed the digits inside each year.

Phone numbers split into their groups, and the groups came back in reverse order. A parser that looks for a phone number pattern may still find one, but not the right one.

Lam-alef and Arabic letter forms

Arabic letters change shape depending on their neighbours, and lam followed by alef is drawn as a single combined glyph. To get text back, a PDF reader needs a map from each glyph to the characters it stands for. The PDF format provides one, the ToUnicode map, and the specification says it is what a reader should use to extract text.

None of the six PDF reads returned the three lines containing lam-alef correctly. “معلومات الاتصال” came back as “معلومات االتصال”, with the pair reversed, or as “معلومات التصال”, with the alef missing. A search for the word as written would not match either.

pdf.js on the Chromium PDF had a second problem. In 10 of 10 Arabic lines it returned Arabic presentation forms: the separate Unicode characters for initial, medial and final letter shapes, kept for compatibility with old encodings. They look the same on screen but are different characters from the ones you typed, so a keyword search for an Arabic job title will not find them.

Invisible direction marks

pdftotext kept the word order of single-script lines, but wrapped every right-to-left line in invisible Unicode direction controls: U+202B (right-to-left embedding) at the start and U+202C (pop) at the end. On the Chromium file, three lines came back correct apart from those marks.

The marks do not show when the text is displayed. They are still characters, so software that compares strings without removing them sees a different word. In mixed lines, pdftotext also put the numbers inside the marks in drawing order.

When the PDF has no text map

With the ToUnicode maps removed from the Chromium file, no reader returned a single line of the 14 intact. This is the same failure that affects any language, covered in our post on dashes, ligatures and smart quotes. For Arabic it is total: the shaped glyphs have no other route back to text.

What to do with a right-to-left resume

These steps follow from the results above. None of them guarantees how a particular employer's parser behaves, but each removes a failure we saw.

• Send DOCX when the application accepts it. It returned all 14 lines exactly, because it stores reading order instead of drawing order.
• If you must send PDF, check its text before you apply. Copy a mixed line from the PDF and paste it into a plain text editor; if English words or numbers jump to the other end of the line, a parser may see the same.
• Where you can, keep English terms, email addresses and phone numbers out of Arabic or Hebrew sentences. Mixed lines failed far more often than single-script ones.
• If the job is advertised in English, an English resume avoids the problem entirely. Many bilingual applicants keep both versions.

Common questions