RTL Text Checker

Detect direction issues, bidi control characters, and mixed-direction problems in RTL metadata.

Localization Tools100% freeNo sign-up required
Paste Arabic, Hebrew, or mixed-direction text to inspect it.

Right-to-left text is where copy-paste localization workflows quietly break. An Arabic subtitle that looked fine in a translator’s document can render scrambled on the App Store when a Latin brand name, a version number, or stray punctuation collides with the Unicode bidirectional algorithm — brackets flip, numbers jump to the wrong side, and sentence order reverses mid-line.

Paste your Arabic, Hebrew, Persian, or Urdu metadata above. The checker identifies which characters are RTL, flags mixed-direction segments likely to render out of order, and reveals invisible bidi control characters (LRM, RLM, embedding marks) that translators’ tools often leave behind in the text.

How to check RTL text

  1. 1

    Paste your localized metadata — title, subtitle, description, or keyword list — into the field above.

  2. 2

    Review the direction analysis: each segment is classified as RTL, LTR, or neutral, so you can see exactly where directions mix.

  3. 3

    Inspect flagged spots — Latin brand names, numbers, and punctuation inside RTL sentences are the usual suspects for reordering bugs.

  4. 4

    Check the invisible-character report for stray bidi controls (LRM/RLM, embeddings) and strip or keep them deliberately, not accidentally.

Why RTL metadata breaks: the bidirectional algorithm in practice

Unicode text has no single direction — each character carries a directionality class, and the bidirectional (bidi) algorithm decides the final visual order at render time. Arabic and Hebrew letters are strongly RTL; Latin letters are strongly LTR; digits, spaces, and punctuation are weak or neutral and inherit direction from their surroundings. Trouble starts at the seams: in a string mixing an Arabic phrase with “MyApp 2.0”, the neutral characters between the Latin name and the version number can resolve unexpectedly, rendering “2.0” before “MyApp” or detaching punctuation to the wrong end of the line.

Parentheses and trailing punctuation are the most visible casualties. A sentence-final period after a Latin word inside an RTL paragraph often appears in the middle of the rendered line, and brackets can display mirrored or seemingly unbalanced because bidi mirroring swaps them in RTL context. None of this is corruption — the underlying characters are fine — it is the visual reordering that misleads, which is why a checker that shows you logical order versus display behavior beats eyeballing the text.

Invisible bidi controls: the characters you can’t see but ship anyway

Translation tools and word processors quietly insert invisible control characters to force text to look right in their own editors: the left-to-right and right-to-left marks (U+200E LRM, U+200F RLM), directional embeddings and overrides (LRE, RLE, LRO, RLO, PDF), and their modern isolate replacements (LRI, RLI, FSI, PDI). Copy that text into App Store Connect and the invisible characters come along. They count against your character limits — meaningful in a 30-character title — and text that depended on the source editor’s rendering can reorder differently on the store.

In the 100-character keyword field they are worse than wasted space: an invisible mark glued to a keyword changes the string Apple indexes, and can stop the term from matching what users actually type. Best practice is to strip all bidi controls from keywords, and to keep at most a deliberate LRM/RLM in display text where a mixed-direction boundary genuinely needs one. This checker makes each invisible character visible with its code point and position so the decision is yours.

Frequently asked questions

Which languages are written right-to-left?

The major RTL scripts are Arabic (used by Arabic, Persian/Farsi, Urdu, and Kurdish among others) and Hebrew (Hebrew and Yiddish). App Store listing localizations in Arabic and Hebrew render RTL, and any metadata containing those scripts is subject to bidirectional text behavior.

Why do numbers and English words look misplaced in my Arabic text?

Digits and Latin words are LTR or direction-neutral, so inside an RTL sentence the Unicode bidi algorithm has to guess how to order them — and at boundaries with punctuation or multiple LTR tokens, its resolution often differs from what the author intended. The characters are stored correctly; only the visual order is surprising.

What are LRM and RLM characters?

Left-to-Right Mark (U+200E) and Right-to-Left Mark (U+200F) are invisible characters that nudge the bidi algorithm at direction boundaries. Used deliberately, they fix misordered punctuation around mixed-direction text; left in accidentally by translation tools, they waste characters and can alter how keywords are indexed.

Do invisible bidi characters count against App Store character limits?

Yes. Every control character occupies space in the field, so stray marks eat into your 30-character title or 100-character keyword budget while displaying as nothing. The checker counts them and shows exact positions so you can strip the unintentional ones.

Should my brand name be transliterated for RTL locales?

Test both. Many global brands keep the Latin form in Arabic and Hebrew listings — users recognize it, and it is often what they type in search — but a transliterated form can capture native-script queries too. Whichever you display, verify the mixed-direction rendering here, and consider covering the other form in that locale’s keyword field.

RTL locales deserve more than a translation pass

Appalize’s Cross-Localization ASO generates clean, native-quality Arabic and Hebrew metadata alongside every other locale — keyword fields researched per market and free of stray bidi characters.

Generate RTL-safe metadata

Related free tools