Right-to-left text in a PDF is four separate problems wearing one name, and a tool can solve the first without touching the other three, which is exactly what makes "we support RTL" such a slippery claim to evaluate from the outside.
**Text direction.** RTL text flows right to left, but numbers and any embedded Latin text within it should still read left to right. Getting this wrong needs the Unicode Bidirectional Algorithm, not just reversing the string.
**Letter shaping.** Arabic letters change form depending on where they sit in a word, an isolated form, an initial form, a medial form, a final form. Skip this and every letter renders in its isolated shape, disconnected from its neighbours, which a native reader immediately recognises as wrong even if every individual glyph is correct.
**Ligatures.** Certain Arabic letter pairs form a single joined glyph, لا being the most common example. Missing ligature support looks unprofessional at best and confusing at worst.
**Digit choice.** Arabic text can use Western digits (0-9) or Eastern Arabic-Indic digits (٠-٩), and which one is correct depends on regional convention, not on the script itself.
## Where we actually stand, problem by problem
Problem one, the font itself: solved, on both the browser tool and, as of this year, the REST API. Choose Arabic, Persian or Urdu, or just write in the script, and the matching Noto Sans Arabic font gets embedded automatically. You get real Arabic glyphs, not empty boxes.
Problems two through four, shaping, ligatures, bidi reordering: not solved, on either surface. Characters draw in the order your content supplies them, in their isolated forms, with no ligature substitution. For a short heading or a label where you control the character order yourself, this is workable, the individual glyphs are correct even if they do not join. For a full paragraph of running Arabic prose, the lack of joining will be visible to any reader who knows the script, and it is not something we would call "supported" with a straight face.
Digit choice: we do not switch digit style automatically. Western digits render regardless of script.
## Hebrew is a different script entirely
Hebrew is not Arabic with different letters, it is its own script with its own Unicode block and its own font requirement, and we do not load a Hebrew font on either surface yet. Text in Hebrew currently falls back to the Latin font and will not render correctly.
## What fixing the rest actually requires
Proper shaping and bidi support need a dedicated text-shaping engine, HarfBuzz is the standard choice, wired into the rendering pipeline on both the browser tool and the API. That is meaningfully more work than embedding a font file, since it changes how every character gets positioned rather than just which glyphs are available. It is on the roadmap, not shipped, and this page will say so plainly until that changes rather than quietly updating the claim after the fact.
If your use case is short Arabic or Persian labels and headings where you control word order, the current state works today. If it is a document of running Arabic or Urdu prose that needs to look correct to a native reader, wait for proper shaping, or use a tool that has already built it.