Arabic, Hebrew, and RTL HTML to PDF that actually renders correctly

Right-to-left text is where most HTML-to-PDF libraries fall apart: reversed Arabic, disconnected letters, tofu boxes where Hindi or CJK glyphs should be. The cause is the same everywhere — the library re-implements text layout instead of using a browser engine. pdfkitt renders with real Chromium and ships the full Noto font family, so Arabic, Hebrew, Devanagari, and CJK come out exactly as they do in your browser.

Send RTL HTML, get a correct PDF

Use standard web markup — dir="rtl" and lang — the same way you would for a web page.

curl -X POST https://api.pdfkitt.dev/v1/convert \
  -H "Authorization: Bearer $PDFKITT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "html": "<html dir=\"rtl\" lang=\"ar\"><body><h1>فاتورة رقم ٤٢</h1><p>شكراً لتعاملكم معنا</p></body></html>",
    "options": { "page_size": "A4" }
  }' --output invoice-ar.pdf

Why browsers get this right and PDF libraries don't

Correct RTL output needs three things working together: the Unicode bidirectional algorithm, complex script shaping (Arabic letters change form depending on position), and fonts that carry the glyphs. Browser engines have had all three for decades because the web is multilingual. Standalone PDF libraries typically implement a subset, which is why RTL bugs in them stay open for years. Rendering through Chromium sidesteps the whole problem class — and the render containers have Noto and Noto CJK installed, so there are no missing-font tofu boxes.

FAQ

Why does Arabic text come out backwards or disconnected in my PDFs?

Most PHP and Python PDF libraries do not implement the Unicode bidirectional algorithm or Arabic letter shaping. DomPDF is a common example: right-to-left text renders reversed or with disconnected letters. Chromium implements bidi and shaping the same way your browser does, so pdfkitt output matches what you see on screen.

Which scripts and languages are supported?

The render environment ships the Noto font family, including Noto CJK - covering Arabic, Hebrew, Devanagari (Hindi), Chinese, Japanese, Korean, and the full Latin, Cyrillic, and Greek ranges. If a glyph exists in Noto, it renders. You can also load your own web fonts with @font-face and they will be fetched and used.

How do I get correct right-to-left layout?

Mark up your HTML the way you would for a browser: set dir="rtl" and the lang attribute on the html element, or use CSS direction and unicode-bidi for mixed-direction content. Chromium handles the rest - mirrored layout, punctuation placement, and numbers inside RTL text.

Do mixed-direction documents work - for example English product names inside Arabic invoices?

Yes. Bidirectional text is exactly what the Unicode bidi algorithm handles, and Chromium implements it fully. Latin fragments embedded in RTL paragraphs keep their direction, and you can control edge cases with the bdi element or unicode-bidi CSS.

Does it execute JavaScript in my HTML?

No. pdfkitt renders static HTML and CSS; page JavaScript is not executed. Render your template server-side and send the final HTML.

Try pdfkitt free — 1,000 PDFs/month, no credit card

Get an API key and render your first Arabic or Hebrew PDF in minutes.

Get started freeRead the docs