Seven specific, recurring mistakes cause most Arabic KDP rejections. Each one has a clear cause, a way to catch it before you submit, and a fix — covered here in full, not as a one-line list.
Verified against Amazon's own current KDP Arabic documentation, reviewed by Ata Rafi, Founder and Chief Formatter at Format Fix.
Request A Free QuoteAmazon's own KDP documentation states plainly: "Arabic is a 'right-to-left' language, so we'll reject files set to left-to-right." This isn't a rendering warning — it's a hard submission block, and it's the single most avoidable rejection on this list.
The manuscript was built from an English or other LTR template and the base text direction was never switched, or the file was assembled in a word processor with Arabic typed into an LTR-configured document rather than one set to Arabic from the start.
Check the document's language and paragraph direction settings directly — not just how the text looks on screen, since some software will visually mirror Arabic without actually changing the underlying direction property KDP reads.
Set Arabic as the editing language and confirm right-to-left paragraph direction at the document level before conversion, not after. See Fixing Arabic Text Direction for how this setting behaves across tools.
KDP requires the ebook content and the book details entered during title setup to both declare Arabic consistently. If "Arabic" isn't selected in the Language menu, or the file's actual language doesn't match what was selected, the submission is flagged.
Authors set the book's language during title setup separately from formatting the file itself, and the two steps happen far enough apart in the process that a mismatch slips through unnoticed.
Cross-check the Language field in KDP's title setup against the actual editing language set inside the manuscript file itself — not just the visible script.
Confirm both settings before uploading, and re-check after any late manuscript edit, since a last-minute change can silently revert the file's language setting.
Blank or box-shaped glyphs ("tofu boxes") appear when a font isn't embedded in the file, or when the font used doesn't actually contain full Arabic glyph coverage despite displaying correctly on the author's own machine.
A font that happens to be installed locally renders Arabic fine on the author's screen, but isn't embedded in the exported file — or a general-market font with incomplete Arabic character and ligature coverage is used without that gap being checked.
Open the converted file on a different device than the one it was built on, ideally one without the same fonts pre-installed — boxes that don't appear on the source machine often surface immediately elsewhere.
Use a font with verified full Arabic glyph and ligature support and confirm it's embedded, not just referenced, in the exported file. See Arabic Font Selection & Licensing for how fonts are checked for this before delivery.
Conversion-Step DisplacementTashkeel (the diacritical marks used for precise pronunciation, especially in Quranic and classical text) are positioned relative to the base letter. The Word-to-EPUB conversion step can shift or drop them if line spacing and font rendering aren't handled correctly beforehand.
Diacritic marks rely on precise vertical positioning that some conversion pipelines don't preserve, particularly when line spacing was set loosely enough in the source file to mask the problem before conversion.
Compare tashkeel placement in the converted EPUB directly against the original manuscript, letter by letter in a sample passage — not just a glance at overall readability.
Set precise, consistent line spacing before conversion and verify diacritic placement afterward rather than assuming it carried over. See Quranic Text & Tashkeel Formatting for how this is handled for text requiring exact diacritic accuracy.
Broken Letter Joining. Arabic letters change shape depending on their position in a word and must join into continuous ligatures. A conversion or export step that isn't Arabic-aware can break that joining, leaving letters floating separately instead of connected.
The EPUB export path strips or mishandles the contextual shaping information Arabic script depends on, usually because the tool or font involved wasn't built with full Arabic shaping support.
Scan the converted file for words where letters appear as isolated forms instead of joined — this is usually visible at a glance once you know to look for it, but easy to miss if you're only skimming for typos.
Confirm the conversion path preserves Arabic shaping data end to end. See Why Does My Arabic Text Look Broken, Reversed, or Disconnected? for the full diagnostic on this exact failure.
Some tools apply text direction uniformly across a paragraph rather than recognizing that embedded numeral sequences need their own left-to-right handling within the surrounding RTL flow.
Check every multi-digit number in the converted file against the source — page references, dates, and numbered lists are the most common places this surfaces.
Verify digit order after each conversion pass rather than assuming it's preserved automatically, since this is a bidirectional text handling issue, not a typo that's easy to spot by reading.
If the title or author name on the manuscript's title page doesn't exactly match what's entered in KDP's book details, that mismatch alone is a stated rejection reason — unrelated to formatting quality.
Every mistake above can be checked before submission rather than discovered after a rejection. This is the same sequence a submission gets reviewed against here before it goes to KDP.
A KDP rejection isn't final — it comes back with a stated reason, and the file can be corrected and resubmitted. The risk is guessing at the fix without knowing exactly which of these seven mistakes caused it, which often leads to a second rejection for a different reason. Diagnosing the actual cause first, then fixing that specific issue, avoids a repeat cycle. Get a quote for a rejected-file diagnosis and resubmission-ready fix, or see DIY vs. Professional Arabic Typesetting if you're deciding whether to fix it yourself.
Authors submitting an Arabic manuscript to KDP for the first time, without a prior file to reference for what passed review.
Writers reusing a print-formatted manuscript for ebook submission, where print-specific settings don't carry over cleanly to EPUB.
Publishers submitting multiple Arabic titles at once, where one uncaught formatting mistake in a shared template repeats across every book.
Submitting a file set to left-to-right instead of right-to-left, a language mismatch between the file and book details, unembedded or non-Arabic-aware fonts causing tofu boxes, tashkeel shifting during conversion, broken letter joining, numerals in the wrong order, and a title/author mismatch.
Amazon's own KDP documentation states that Arabic is a right-to-left language and files set to left-to-right will be rejected outright — this is a hard submission block, not a formatting suggestion.
Tofu boxes appear when a font isn't embedded in the exported file, or when the font used doesn't have full Arabic glyph coverage, even if it displayed correctly on the device it was built on.
Tashkeel marks rely on precise positioning relative to the base letter, and the Word-to-EPUB conversion step can shift or drop them if line spacing and font rendering weren't set correctly beforehand.
Arabic letters must join into continuous ligatures based on their position in a word. A conversion or export path that isn't Arabic-aware can break that joining, leaving letters as isolated, floating forms.
Numerals read left-to-right even inside right-to-left Arabic text. If a conversion step applies right-to-left logic to a digit sequence instead of treating it as its own left-to-right unit, the digit order reverses.
Yes, once the specific cause is identified — KDP rejections come with a stated reason. The risk is fixing the wrong thing and triggering a second rejection for a different cause, which is why diagnosing the actual mistake first matters more than guessing at a general fix.
