Guide
Hebrew or Arabic text reversed when copied from a PDF
You copy a line of Hebrew or Arabic out of a PDF and it pastes backwards. Why it happens, a ten-second test that tells file from app, and how to fix it.
About 6 minutes · quick
What is going on
A PDF holds two separate things: the picture on the page and the text behind it. Usually they agree. With Hebrew and Arabic they often do not.
Many producers — older report generators, print drivers, legal and government systems, some OCR engines — handle right-to-left text the short way: they reverse each line in advance and paint it left to right, like English. On screen and on paper it is indistinguishable from a correct file. But the characters are stored in visual order, the reverse of the order you read them in.
Everything that reads the characters instead of the picture gets them backwards:
| What reads the file | What it gets |
|---|---|
| Your eyes | A correct line |
| Copy and paste | The line backwards |
| Find in the PDF | Nothing — the word is stored reversed |
| A screen reader | The line from the end, or reversed twice if it “corrects” direction |
| A search engine | Possibly the reversed text |
The ten-second test
- Select one line of Hebrew in the PDF and copy it.
- Paste it into a plain text editor, a Word document, or your browser’s address bar.
- Look at the final letters — ך ם ן ף ץ.
They only ever end a word in Hebrew. If שלום pasted as םולש, with the ם at the start, the file itself stores the text reversed. That is a more reliable signal than “it looks backwards”, because a program without right-to-left support can make correct text look wrong while the letters themselves are fine.
Arabic gives itself away the same way. Taa marbuta (ة) and alif maqsura (ى) only end a word, and the definite article ال only begins one — reversed, it turns up as لا at the end. Arabic can also carry a second, separate fault: some files store its letters as presentation forms, the shaped glyph variants, so pasted text looks right but does not match the same word typed normally. That breaks search even when the order is correct.
Why ordinary checkers pass these files
PDF/UA and the Matterhorn Protocol — the basis of veraPDF, PAC and Acrobat’s checker — test tags, structure, language, fonts and alternate text. None of their failure conditions asks in which direction the characters were stored. So a reversed Hebrew file can pass all three and still read backwards. The failure, in detail →
How to fix it
If you have the source, re-export
This is the clean fix. Word, Google Docs and current versions of InDesign with right-to-left support write text in logical order — the order it was typed in. Re-export, repeat the copy test, and if the Hebrew pastes correctly you are done. A report generator or a payroll system that produces reversed PDFs often has a single “Unicode” or “logical Hebrew” export setting that fixes every future file at once.
If you do not, attach the right text — do not reverse the picture
Reversing the characters inside the file is not a fix. Numbers, dates and Latin words inside a Hebrew line were stored the right way round, and blind reversal breaks them. And changing the characters changes what is painted, so a document of record no longer looks like itself.
The mechanism the standard provides is ActualText: each piece of structure carries its text in logical order, and copy, search and screen readers read that instead of the painted glyphs, which do not move. In Acrobat you can type ActualText into a tag’s properties one tag at a time — workable for a page, not for twenty.
What Taggart does
Taggart’s free checker detects visual-order storage line by line from two independent signals — the direction the producer painted in, and where final and initial letters fall — and shows each line as stored, in logical order, and the evidence for the verdict. Lines where the evidence is weak are reported as undecided, not counted as fine.
The repair attaches the logical text as ActualText, with the line’s language, and never touches how the page looks: every repaired page is compared with the original, and a repair that changes the picture is thrown away. When a producer puts several lines of a paragraph into one piece of content — common in real documents — every line gets its text; none is left silent.
Check a file free — no account, and the right-to-left tab shows every line.
Frequently asked questions
Why does Hebrew come out backwards when I copy it from a PDF?
Usually because the PDF stores it that way. Many producers reverse each right-to-left line in advance and paint it left to right, like English. The page looks perfect, but anything that reads the characters rather than the picture — copy and paste, search, a screen reader — gets them in stored order, which is backwards.
Is it the PDF or the program I pasted into?
Look at the Hebrew final letters: ך ם ן ף ץ occur only at the end of a word. If they sit at the start of words in what you pasted, the file stores the text reversed. If the letters are right but the line is laid out oddly, the program you pasted into is the problem — a plain terminal or an old editor without right-to-left support will display correct text badly.
Can I just reverse the text back?
For one line of plain words, yes. For anything with numbers, dates or English inside it, no: those were stored in the right order, so reversing everything turns 2014 into 4102. The reliable fixes are to re-export from the source document, or to attach the correct text to the PDF as ActualText.
Does this affect people who do not use screen readers?
Yes. Search inside the PDF fails, copied text is unusable, and a search engine that extracts the text may index it reversed, so the document cannot be found by its own words. For screen-reader users it is the difference between a document and noise.
Related guides
- Hebrew PDF accessibility: the three failures that matterVisual-order storage, wrong document language, and left-to-right column order. All three are invisible to a sighted reviewer and to every mainstream checker.
- Arabic PDF accessibility: what breaks and whyArabic adds contextual letter shaping and ligatures on top of every right-to-left problem Hebrew has. What that does to extracted text, and how to check it.
- ActualText in PDF: what it is and when to use itActualText changes what a PDF says without changing how it looks. When it is the right fix, how it differs from Alt, and the mistakes that silence text.
Related failure conditions
- TG-RTL-001 Right-to-left text is stored in visual orderOlder Israeli government, legal and DTP systems lay out Hebrew by reversing the character order and then rendering left-to-right. The page looks correct, but the stored text is backwards. Extracting it gives you the sentence mirrored, and the bidi algorithm then reverses it a second time.
- TG-RTL-003 A mixed-direction run is not correctly orderedHebrew sentences containing English product names, dates, percentages or citation numbers are the hardest bidi case. Producers frequently reverse the RTL and leave the LTR runs alone, or reverse everything.
- TG-RTL-005 Right-to-left punctuation or numerals are misplacedA full stop that renders at the left edge of a Hebrew line must be stored at the end of the logical string, not the beginning. Brackets must be stored as the logical opening/closing character, not the visually mirrored one.
- 10-001 Character code cannot be mapped to UnicodeA glyph is painted whose character code has no Unicode equivalent reachable through the font's ToUnicode CMap, encoding, or glyph names. The text renders correctly but cannot be extracted.
Check your own file. Taggart's validator is free and unlimited — no page cap, no watermark, and no account at all up to 60 pages.
Last updated .