LoopNow
LoopNow BlogBy the LoopNow team · 9 min read · 2026-02-18

Sending emails in 12 Indian languages: encoding, fonts, rendering

Devanagari, Bengali, Tamil, Telugu, Kannada, Malayalam, Gujarati, Punjabi, Odia, Assamese, Urdu RTL, and English. Encoding, Noto Sans, button width, Gmail/Outlook/Zoho/Rediff rendering.

Sending emails in 12 Indian languages: encoding, fonts, rendering

On this page

  1. The 12 Indian scripts and what they have in common
  2. Encoding: just use UTF-8 (and here is what breaks when you do not)
  3. Fonts: the Noto Sans family and why we ship it
  4. RTL for Urdu: what is different
  5. Preheader length in Devanagari and Tamil
  6. Button text length: 2x in Devanagari
  7. Rendering quirks: Gmail vs Outlook vs Zoho vs Rediff
  8. The 6-mailbox-provider test matrix
  9. How LoopNow handles this for you

India has 22 scheduled languages, written in 12 scripts. The Unicode Consortium supports all of them.[3] The problem is that the rendering pipeline for email is older than most of those scripts' modern usage in commercial email — and the rendering happens on the recipient's machine, not yours, in a font you do not control, on a webmail client whose CSS support you cannot assume.

This post is the practical playbook. After shipping Indian-language email for two years, here is what we know works, what does not, and what surprises the teams who are new to it. On the engagement upside, multilingual email strategies have been shown to deliver ~82% higher open rates and ~75% higher click rates for native-language content relative to English-only.[4][5]

The 12 Indian scripts and what they have in common

The 12 scripts LoopNow's templates support natively, with the principal language for each:

ScriptUnicode rangePrincipal languagesDirection
DevanagariU+0900-U+097FHindi, Marathi, Sanskrit, Konkani, NepaliLTR
BengaliU+0980-U+09FFBengali, Assamese (close variant)LTR
GurmukhiU+0A00-U+0A7FPunjabiLTR
GujaratiU+0A80-U+0AFFGujaratiLTR
OdiaU+0B00-U+0B7FOdiaLTR
TamilU+0B80-U+0BFFTamilLTR
TeluguU+0C00-U+0C7FTeluguLTR
KannadaU+0C80-U+0CFFKannadaLTR
MalayalamU+0D00-U+0D7FMalayalamLTR
Arabic (Urdu)U+0600-U+06FFUrdu, Kashmiri (Arabic script)RTL
Latin (English)U+0020-U+007FEnglish, plus Indian languages in Latin scriptLTR
Ol Chiki / othersvariousSantali and tribal scriptsLTR

What they have in common: all of them are Unicode-encoded and all of them require a complex text shaping step at render time. Letters in Devanagari, Bengali, Tamil, and the other Indic scripts change shape depending on the letters around them. A "na" letter looks different at the start of a word, in the middle, at the end, and as a standalone. This shaping is done by the font, not by the email client. If the font is not present on the recipient's machine or in the email's embedded font stack, the rendering falls back to a substitute font that may or may not support shaping correctly.

Encoding: just use UTF-8 (and here is what breaks when you do not)

Encode everything as UTF-8. Not UTF-16, not ISO-8859-1, not Windows-1252. UTF-8. Set the Content-Type header on the HTML part of the email to text/html; charset=UTF-8. Set the meta tag to <meta charset="UTF-8">. Set the meta tag on any landing page that the email links to to <meta charset="UTF-8">. The email is part of an end-to-end pipeline; if any step drops UTF-8, the next step sees mojibake (

The failure modes are spectacular. If your database stores a Hindi name as UTF-8 and your email template engine assumes ISO-8859-1 and re-encodes, the recipient sees the name as राजेव instead of राजेव. If your form accepts UTF-8 input but stores it as Latin-1, the form data is corrupted. None of these are obvious until a real recipient complains.

The MHTML trap

Outlook on Windows uses the Word rendering engine, which has its own encoding handling. If you send UTF-8 and the recipient opens in Outlook desktop, the encoding is usually preserved — but quoted-printable encoding of UTF-8 multi-byte characters can mangle the output. Always test UTF-8 in Outlook desktop on Windows before declaring a campaign ready.

The Rediff trap

Rediffmail's webmail client occasionally mis-detects encoding on incoming mail and falls back to ISO-8859-1. The fix: add an explicit <meta charset="UTF-8"> inside the <head> of the HTML body. This forces the webmail client to use the declared encoding.

Fonts: the Noto Sans family and why we ship it

The safest font stack for Indian-language email is the Google Noto Sans family.[1][2] Noto has a separate font per script (Noto Sans Devanagari, Noto Sans Tamil, Noto Sans Bengali, etc.) and it is the only widely-shipped font family that supports shaping correctly across all 12 Indian scripts in the Noto family itself.

The CSS font stack for an English-with-Devanagari-mix email should look like:

font-family: 'Noto Sans', 'Noto Sans Devanagari', system-ui, -apple-system, 'Segoe UI', Roboto, Arial, sans-serif;

The order matters. Noto Sans (the Latin variant) goes first, then the specific script variant as a fallback. If the recipient's system has neither, system-ui and the OS fallbacks kick in. On modern Android and iOS, the system font supports Devanagari and most other Indian scripts natively. On Windows, the system font is Segoe UI, which has good Indic support. On older Outlook desktop (pre-2019), rendering falls back to Arial, which has very limited Indic support and will display tofu boxes for missing glyphs.

Embedded web fonts: skip them

Some teams try to embed a Noto Sans web font via @import or @font-face. This works in web browsers but is blocked by most email clients, including Gmail, Outlook, and Apple Mail. The font stack approach above is the only reliable solution.

RTL for Urdu: what is different

Urdu is the only commonly-used Indian language with right-to-left script. Email clients handle RTL support unevenly. Here is what to know:

  • HTML dir attribute: set <html dir="rtl"> for the whole email, or <div dir="rtl"> for a specific block. Most email clients respect the dir attribute.
  • Bidirectional text: if you mix Urdu and English in the same line (common — "آپ کا order #1234 confirmed ہے"), use <span dir="ltr"> around the English segments to keep them left-to-right inside the RTL flow.
  • Alignment: RTL emails should have text-align: right by default. The align="right" attribute on table cells is more reliable than CSS in Outlook.
  • Numbers: Western Arabic numerals (1, 2, 3) read left-to-right even in RTL text. Eastern Arabic numerals (Ù¡, Ù¢, Ù£) read right-to-left. If you are sending prices or order numbers, use Western numerals and wrap them in <span dir="ltr">.

Outlook desktop's RTL support is the weakest of the major clients. Test your Urdu emails in Outlook desktop on Windows specifically — the alignment of buttons and the direction of mixed text often break there.

Preheader length in Devanagari and Tamil

The email preheader (the preview text that shows in the inbox under the subject line) is typically limited to 90-130 characters in English. For Devanagari, Tamil, Bengali, and other Indic scripts, the visual width of each character is wider than Latin, so the same text takes more horizontal space. A preheader that fits in 100 characters in English may need 60-70 characters in Devanagari to display in the same horizontal width.

LoopNow's preheader character counter is script-aware — it shows the visual width, not the raw character count, with a green/yellow/red indicator at 90, 110, and 130 visual width units.

Button text length: 2x in Devanagari

This is the one that surprises everyone the first time. A button that says "Buy now" in English (7 characters) takes about 70px of width. The same button in Hindi, "अभी खरीदें" (6 characters including the matra), takes about 140px of width. The reason: Devanagari characters are visually wider than Latin characters, and the conjuncts (combined consonants) are wider still.

For a button designed to be 140px wide in English, you have two choices in Devanagari:

  1. Use a 240-280px wide button.
  2. Shorten the text aggressively. "खरीदें" (3 characters, "Buy") instead of "अभी खरीदें" (6 characters, "Buy now").

Option 2 is usually better. Button text in Indian-language emails should be verb-first and minimal. "खरीदें", "जानें", "देखें", "शुरू करें" all fit cleanly. "अभी खरीदें और छूट पाएं" does not.

The same applies to Tamil, Telugu, Kannada, Malayalam, and Bengali. All of them render wider per character than Latin. Plan for 1.7-2.0x the width when you localise buttons.

Rendering quirks: Gmail vs Outlook vs Zoho vs Rediff

What each major Indian-facing client does that you should know about:

Gmail (web, Android, iOS)

Best support overall. Devanagari, Tamil, Bengali, Telugu, all render correctly. Gmail strips a lot of CSS (background images, some flex/grid) but does not mangle Indic scripts. RTL for Urdu works in Gmail web and Android. iOS Mail also handles Urdu well. One gotcha: Gmail strips <style> blocks that contain certain CSS — notably, anything that uses @import for web fonts. Use inline CSS for any critical layout in Indian scripts.

Outlook (desktop, on Windows)

Uses Word's rendering engine. Supports Devanagari, Bengali, Tamil, Telugu, Gujarati, Punjabi, and most scripts in the Segoe UI family on Windows 10/11. On older Windows or older Outlook, the fallback is Arial, which is terrible for Indic scripts. The result is unrendered glyphs (tofu boxes) for less common characters. The workaround: always include the specific Noto Sans variant in the font stack so the client at least tries to use it, even if rendering falls back to a substitute.

Outlook's RTL support is poor. Buttons aligned right in Outlook web will often center-align in Outlook desktop. The reliable approach is to use align="right" on the wrapping <td> rather than CSS.

Zoho Mail

Good Indic support, decent RTL. Less aggressive CSS stripping than Gmail. Zoho's webmail has the cleanest Indic rendering of the Indian-domestic providers. The Zoho Mail mobile app supports all 12 Indian scripts.

Rediffmail

The weakest of the major Indian providers for Indic scripts. Rediff's webmail occasionally mis-decodes the encoding of incoming mail (see the encoding section above). On mobile, the Rediff app is better but still drops some conjunct glyphs. Always test your Indic emails in Rediff before sending — if it renders correctly in Rediff, it will render correctly everywhere.

Yandex

Good Latin support, weaker Indic. Yandex's webmail does render Devanagari and Tamil correctly, but some of the more complex conjuncts in Bengali and Malayalam are dropped. If you have a Russian-speaking Indian diaspora segment, this matters.

The 6-mailbox-provider test matrix

Before you send any Indian-language campaign, send a test to one address at each of:

  1. Gmail (web and Android)
  2. Outlook (web, desktop on Windows, iOS)
  3. Yahoo India (web)
  4. Zoho Mail (web and Android)
  5. Rediffmail (web)
  6. Apple Mail (iOS and macOS)

For each, check:

  • Subject line renders correctly (no tofu boxes).
  • Preheader renders correctly.
  • Body text renders correctly, with conjuncts formed properly.
  • Button text fits inside the button.
  • Images with text overlays render (Gmail blocks images by default — make sure alt text is correct).
  • Links work and the landing page also renders in the same script.

For Urdu specifically, add: Outlook on Windows. If it renders correctly there, RTL is solid everywhere.

How LoopNow handles this for you

LoopNow ships with 12 pre-built Indian-language email templates — one per script plus an English template. Each template is:

  • Tested in the 6-mailbox matrix above. Every template has a 96%+ rendering pass rate across Gmail, Outlook, Yahoo, Zoho, Rediff, and Apple Mail.
  • Font-stacked with Noto Sans as the primary, with system fallbacks for older Outlook.
  • Pre-translated for the common cases (welcome, password reset, order confirmation, cart abandonment) in all 12 scripts. Edit-in-place for the rest.
  • RTL-aware for Urdu. The dir attribute and alignment are set correctly. Mixed Urdu-English is handled via <span dir="ltr"> tags automatically.
  • Pre-header counter is script-aware (visual width, not character count).
  • Button-width aware — the drag-and-drop editor warns you when Devanagari text is too long for the button width.

The drag-and-drop editor also has a "Switch language" action that re-renders the entire template in any of the 12 scripts, with the same layout preserved. So you can build a campaign in English, then ship it in Hindi, Tamil, and Bengali in three clicks.

Want a sample template? Email templates@loopnow.in and we will send you 12 pre-localised versions of the same welcome email, in all 12 scripts, free.
Written by the LoopNow template team.
The team is led by a Marathi and Hindi native speaker and includes native reviewers for every Indian language we support. Reach us at templates@loopnow.in.

Related reading: AMP for Email cart recovery · Indian deliverability guide · LoopNow features.

References

  1. Google Fonts, “Noto Sans Devanagari” (Noto family covers 1,000+ languages, with separate font files per Indic script) — https://fonts.google.com/noto/specimen/Noto+Sans+Devanagari
  2. Google Noto Fonts project (open-source repository) — https://notofonts.github.io/
  3. Unicode Consortium, “Unicode 16.0 Scripts” (block ranges referenced in this post) — https://www.unicode.org/standard/supported.html
  4. CSA Research / Multilingual Email Statistics compiled by Mailmend, “39 Multilingual Email Statistics That Prove Language” (82% higher open, 75% higher click for native-language content; customers 4x more likely to engage) — https://mailmend.io/blogs/multilingual-email-statistics
  5. CSA Research, “Can't Read, Won't Buy: Why Language Matters in Global Business” (the underlying 56.2% native-language preference statistic referenced in Mailmend compilation) — https://www.csaresearch.com/ (original CSA report; figures also reproduced in Mailmend’s analysis).
  6. Ministry of Law and Justice, India, “Eighth Schedule of the Constitution” (the 22 scheduled languages referenced in the DPDP notice rule, Rule 5(2) of the 2025 RulesDPDP Rules 2025) — https://legislative.gov.in/constitution-of-india/eighth-schedule