Most PDF generation tools default to Latin fonts, so sending Hindi text like "नमस्ते दुनिया" gets you either an empty box for every character, or nothing at all. This is the actual reason: a font file only contains the glyphs someone drew into it, and the built-in fonts most PDF libraries ship with were drawn for Latin scripts. No amount of correct Unicode handling in your code fixes a font that simply does not have the character.
## What we cover, script by script, not language by language
A font covers a script, not a specific language, so one Noto Sans Devanagari file handles Hindi, Marathi, Sanskrit and Nepali at once, and one Noto Sans Arabic file handles Arabic, Persian and Urdu. The right mental model is script coverage, not a checklist of language names.
**Devanagari**, Noto Sans Devanagari. Covers Hindi, Marathi, Sanskrit, Nepali. **Arabic script**, Noto Sans Arabic. Covers Arabic, Persian, Urdu. **Latin**, the built-in font, no fetch needed. Covers English and most European languages.
The font is fetched and embedded only when your content actually contains that script, so a plain English document costs nothing extra and stays the same size it always was.
## What changed: the API catches up to the browser tool
Until recently, only the [browser tool](/text-to-pdf) did this. The REST API rendered with a built-in font that covered Latin only, so Devanagari or Arabic sent to the API came back broken while the exact same text worked fine in the browser.
That gap is closed. `POST /api/pdf/generate` now detects the script in your content, or trusts an explicit `language` field if you send one, and embeds the matching font before rendering, the same mechanism the browser tool has used for a while. If you built an integration around the old workaround, routing non-Latin content to the browser tool because the API could not handle it, that workaround is no longer necessary; the API call now does the right thing directly.
## What still is not covered, and won't be pretended to work
Chinese, Japanese and Korean are not supported on either surface. The reason is specific rather than "not implemented yet": the Noto fonts for these scripts ship as OTF or CFF files, and the PDF library both surfaces are built on can only parse TrueType. It is not a missing feature so much as a format mismatch that needs a different rendering approach entirely to fix. Sending CJK text to the API now returns a warning naming this rather than silently producing blank output, which is the honest version of what used to happen invisibly.
Hebrew and Thai are also not covered by either surface, for the same underlying reason, different scripts, same format problem.
## The one Arabic caveat worth knowing before you ship
The Arabic glyphs render correctly, but neither surface does full bidirectional text reordering or contextual letter joining, the shaping that makes Arabic letters connect into the flowing forms a native reader expects. What you get is legible, correctly-shaped individual letters in a readable order for short text like headings or labels. For a long paragraph of running Arabic prose, the lack of proper joining will be visible to anyone who reads the script. Real shaping needs a library like HarfBuzz, which is a larger piece of work than embedding a font, and it is on the list rather than done.
We would rather tell you this here than have you find it on a document already sent to someone.