Working with Arabic PDFs

You open an Arabic contract, select a paragraph, copy it, and paste it into an email. What lands is a row of disconnected letters — or the right letters in the wrong order, or a string of characters that look almost right and aren't. The PDF displays perfectly. The moment you try to take the text out, it falls apart. This isn't your software being broken. It's a genuinely hard problem showing through.

Why Arabic is harder than Latin script

English asks very little of a text system: letters sit in a row, left to right, each one the same shape wherever it appears. Arabic asks for considerably more, and every one of these features is a place where tools go wrong:

It's cursive by nature. Letters join. This isn't decorative — it's how the script works.
Letters change shape by position. A single letter can have up to four forms: standing alone, at the start of a word, in the middle, at the end. Same letter, same meaning, four different pictures.
It runs right to left — but not everything does. Numbers and embedded Latin words run left to right inside right-to-left text.
Diacritics are optional and meaningful. Short vowel marks may be present or absent, and they change the reading.

So displaying Arabic correctly requires the renderer to pick the right shape for every letter based on its neighbours, then lay out mixed-direction runs coherently. Both steps are where the trouble comes from.

The short version: a PDF stores pictures of letters and a note about where to draw them. For Latin script you can usually work backwards from picture to character. For Arabic, that path is lossy — which is why the page looks perfect and the copy doesn't.

Shaping, and why copy-paste breaks

Here's the mechanism, because knowing it explains every symptom you'll meet.

Text is stored in logical order — the order you'd say it. Before drawing, the software applies shaping: choosing the correct positional form for each letter, and bidi (the bidirectional algorithm), which works out how right-to-left and left-to-right runs interleave on the line.

A PDF, though, doesn't store your sentence. It stores glyphs — indices into a font — plus positions. The shaping has already happened and been baked in. To copy text back out, the reader needs a map from glyph back to character, which the file may include as a ToUnicode table. And that's the crux:

No map, no text. If the generator didn't include one, extraction yields glyph numbers, not letters. You get garbage that renders fine and means nothing.
A map to the wrong thing. Some generators map glyphs to presentation forms — a legacy Unicode block holding each pre-shaped variant separately. Text extracted that way looks correct on screen but isn't normal Arabic: search won't match it, and other software won't handle it properly.
Order lost. If the file stores glyphs in visual order without the information to reverse it, you get letters in drawing order rather than reading order — the classic "backwards" paste.
Joins broken. Extraction that recovers isolated letters without their connections produces that row of disconnected characters, each one individually correct.

Notice what this means: whether Arabic copies out of a PDF properly was decided by whatever produced the file, often years ago. No reader can fully recover information the generator threw away.

What you can do about a file that won't give up its text

Try extracting first. If the document was made by a competent generator, the text is there and copies cleanly. Always worth thirty seconds before anything heavier.
Try a different reader. Readers differ in how well they reverse shaping and handle bidi. A file that pastes badly from one can paste correctly from another.
If it's a scan, it was never text. Then no amount of copying will work, and OCR is the only route — see below.
If extraction gives presentation forms, you have text, but the awkward kind. It may need normalising before it's searchable alongside ordinary Arabic.

Arabic OCR: harder, and honest about it

When the document is a scan, recognition is the only path — and it's markedly harder for Arabic than for English. Every feature above works against the engine: letters connect, so there's no clean gap to cut between characters; shapes vary by position, multiplying what must be recognised; dots above and below distinguish otherwise identical letters, so a speck of scanner noise can change the word; diacritics may or may not be present.

The practical consequences are worth stating plainly:

Scan quality matters even more than usual. 300 dpi, high contrast, straight. With Arabic, a mediocre scan doesn't degrade gracefully.
Use the Arabic model. OCR Arabic — an English model on Arabic text produces nothing useful.
Expect to proofread. Clean machine-printed Arabic yields good results. Good is not perfect, and the errors tend to be single-dot differences that change meaning rather than obvious nonsense.
Handwriting is out. Not a supported use case in any language, and Arabic handwriting especially so.

OCR runs on your own device and is part of CyvoDocOps Pro; because Pro is purchased through the App Store or Google Play rather than on the web, the OCR tools live in the mobile app. For the general background on how recognition works, see making a scanned PDF searchable.

Stamps and annotations in RTL documents

Arabic business documents lean on stamps and seals far more than Western ones — approvals, receipts, official endorsements. Adding them to a PDF brings its own wrinkles: the text inside the stamp needs correct shaping, and placement conventions follow the reading direction, so a stamp that looks natural on a left-to-right page can sit awkwardly on a right-to-left one.

Arabic Stamps handles the shaping so the text renders as joined Arabic rather than a line of separated letters — the failure mode you get from tools that treat Arabic as if it were Latin with different characters. Related tools like date stamps and initials follow the same pattern.

Practical habits for Arabic documents

Keep the source. The original from the software that made it will always give better text than anything recovered later.
Test extraction before you commit. If a workflow depends on searching Arabic PDFs, check that text actually comes out of a sample before building around it.
Prefer real text over scans. A born-digital Arabic PDF beats a scan every time. Scan only when paper is the only source.
Mind mixed content. Documents combining Arabic with English terms, invoice numbers and dates are where bidi problems concentrate. Check those lines specifically.
Don't judge by appearance. A file that displays beautifully can still be a scan, or carry an unusable text layer. Try selecting a word — if nothing highlights, it's a picture.

Why local processing matters here

Arabic-language documents that need this kind of work are typically the official ones: contracts, government paperwork, commercial registrations, ID documents, notarised records. That's precisely the category where uploading to a third-party service is least appropriate — and where "we delete after an hour" is a promise you cannot audit. In CyvoDocOps, supported operations run locally in your browser, and the on-device OCR in the mobile app processes scans without sending them anywhere. See Arabic PDF tools for what's available.

See the Arabic PDF tools

Frequently asked questions

Why does Arabic text come out disconnected when I copy it from a PDF?

Because the PDF stores pre-shaped glyphs and the map back to real characters is missing or wrong. The page draws correctly; the information needed to reconstruct the original text was discarded when the file was made.

Why is the text backwards when I paste it?

The file stored glyphs in drawing order without enough information to recover reading order. Some readers reverse it correctly and others don't — trying a different reader is a genuine fix.

Is Arabic OCR as accurate as English?

No, and anyone claiming otherwise is overselling. Connected letters, position-dependent shapes and meaning-carrying dots all make it harder. Clean printed scans give good results that still deserve proofreading.

Can I search an Arabic scanned PDF?

Not until it has a text layer. Run OCR to add one — though note that a negative search result in an OCR'd document isn't proof the word is absent.

Are my Arabic documents uploaded?

No. Supported web operations run locally in your browser, and OCR in the mobile app runs on your device. The document is not sent to a server.