Character Encoding in Email: UTF-8, Diacritics & Non-ASCII Deliverability

2026 Current

UTF-8 is now the universal standard for email character encoding. Most modern email clients handle UTF-8 flawlessly, but some corporate and international clients still have charset issues. Always declare charset explicitly in your email headers.

Charset Declaration: UTF-8 Standard

Every email must declare its character encoding in the `Content-Type` header. This tells the mail client how to interpret bytes. UTF-8 is the universal standard for modern email. If you omit the charset declaration, mail clients may misinterpret special characters.

Proper Charset Declaration (HTTP Mime Header):


Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Email Subject</title>
</head>
<body>
  Café ☕ Naïve résumé Señor
</body>
</html>

Critical Rules:

Always declare `charset=UTF-8` in Content-Type header
Also declare `` in HTML `` (redundant but safe)
Use `Content-Transfer-Encoding: 8bit` for UTF-8 (tells ISPs bytes are not ASCII-only)
Save your template file as UTF-8 (not ASCII, not Latin1)
Test in Gmail, Apple Mail, Outlook to verify rendering

Non-ASCII Characters & Deliverability

Non-ASCII characters (accents, emoji, international symbols) are fully supported in UTF-8 emails. However, improperly encoded non-ASCII characters in subject lines or sender names can trigger spam filters.

Deliverability Rules for Non-ASCII Characters:

Subject line: UTF-8 supported but risky — some spam filters penalize non-ASCII subjects (+0.3-1.0 points)
Sender name: Accents supported; emoji in sender name not recommended
Email body: No penalty for UTF-8 encoded accents or symbols
HTML entities: Safe but outdated; prefer direct Unicode in UTF-8
Emoji: Full support in body; minimize in subject/sender (better open rates without emoji)

Real Scenario (Non-ASCII Subject Line Impact):


Campaign A Subject: "Café Meeting Tomorrow"  (UTF-8 accented é)
Campaign B Subject: "Cafe Meeting Tomorrow"   (ASCII fallback)

Results (1M subscribers each):
  Campaign A: 22% open rate, 0.08% spam complaint
  Campaign B: 24% open rate, 0.04% spam complaint

Impact: 2% lower opens due to spam filtering or subscriber hesitation
Lesson: For critical subject lines, stick to ASCII for best deliverability

Diacritics, Accents & International Text

Accents and diacritics are fully supported in modern email clients when UTF-8 is properly declared. Email body content with accented characters renders flawlessly in 99%+ of cases.

Supported Accented Characters (UTF-8, all clients):

French: café, école, résumé, naïve, élève
Spanish: señor, niño, año, piñata
German: über, äpfel, größe, schön
Portuguese: São Paulo, açaí, avô
Italian: città, più, così

Testing Accented Characters in Email:

Write email with accented text
Declare charset=UTF-8 in headers and `` tag
Send test to Gmail, Apple Mail, Outlook
Verify characters render correctly (no mojibake/garbled text)
If any client shows garbled text, use HTML entities as fallback

HTML Entities vs Unicode

HTML entities encode special characters as `&name;` or `&#number;`. Unicode is the direct representation. In UTF-8 emails, direct Unicode is better.

HTML Entities vs Unicode Comparison:


Character: © (copyright symbol)

HTML Entity: ©
  - Human-readable in source code
  - Works in legacy clients
  - Takes more bytes (6 chars vs 1 char)

Unicode (UTF-8): ©
  - Direct character
  - Most efficient
  - Preferred for modern emails

Character: é (e with acute accent)

HTML Entity: é
  - Takes 8 bytes in source

Unicode (UTF-8): é
  - Takes 2 bytes in UTF-8
  - More readable in templates
  - Cleaner HTML

Common HTML Entity Examples:

`©` = © (copyright)
`®` = ® (registered trademark)
`™` = ™ (trademark)
` ` = (non-breaking space)
`—` = — (em-dash)
`“` = " (left smart quote)
`”` = " (right smart quote)

When to Use Each Approach:

Use Unicode directly: Modern emails (99%+ of cases), UTF-8 declared, body content, readable source
Use HTML entities: Legacy/corporate audience, defensive coding for old Lotus Notes, when UTF-8 support is uncertain
Never mix: Stick to one approach throughout the email; mixing causes encoding confusion

Control Characters & Invisible Issues

Invisible control characters in your email can cause rendering issues, display glitches, and spam filter penalties. The most common offender is the Byte Order Mark (BOM).

Problematic Control Characters:

BOM (Byte Order Mark) — EF BB BF in hex — appears as invisible character at file start
Zero-width space (U+200B) — Invisible but takes up "space" in text
Zero-width non-joiner (U+200C) — Used for padding (in plain text emails), invisible
Direction override (U+202E) — Changes text direction unexpectedly
Soft hyphen (U+00AD) — Invisible; can split words randomly

BOM Problem Example:


File saved with BOM:
[EF BB BF] <!DOCTYPE html>...

What email client shows:
ï»¿<!DOCTYPE html>...

Solution:
  - Save file as UTF-8 WITHOUT BOM
  - In most editors: "UTF-8 (no BOM)" or "UTF-8-noBOM"
  - VSCode: File > Save with Encoding > UTF-8
  - Sublime: File > Save with Encoding > UTF-8

How to Detect Invisible Characters:

Visual inspection: Look for unexpected symbols at file start (Â¿ indicates BOM)
Hex editor: Open template in hex editor (VSCode with Hex Editor extension); look for EF BB BF at file start
Online validator: Paste HTML into https://validator.w3.org/; reports encoding issues
Command line: `file template.html` shows encoding including BOM presence

Quoted-Printable Encoding

Quoted-Printable (QP) is a legacy encoding that converts non-ASCII bytes into readable `=XX` pairs. It's less common in 2026 but still used by some systems.

Quoted-Printable Example:


UTF-8 Direct: "Café"

Quoted-Printable: "Caf=C3=A9"
  (C3 = first byte of UTF-8 é, A9 = second byte)

In an email:
Content-Transfer-Encoding: quoted-printable

Hello! This is a Caf=C3=A9.

What recipient sees: "Hello! This is a Café."

Quoted-Printable vs Base64 vs 8bit:

Quoted-Printable: Readable but bloated (=C3=A9 is 6 bytes for one character)
Base64: Compact but unreadable (RXhlY3V0aW5nIG1lIHdvdWxkIGJl)
8bit (UTF-8 direct): Clean, efficient, modern (used by most modern ESPs)

When QP Still Matters: Some corporate email gateways and old systems (Lotus Notes, legacy Exchange) use QP. If your audience is predominantly corporate, QP might be applied automatically by their system. Most ESPs handle this transparently.

Email Client Charset Support

Modern email clients universally support UTF-8. Legacy systems have variable support. Always test with your actual audience's mail clients.

Charset Support Matrix (2026):

Gmail (Web, App) — Perfect UTF-8 support, handles all Unicode
Apple Mail (macOS, iOS) — Perfect UTF-8 support
Outlook.com — Perfect UTF-8 support
Outlook Windows — UTF-8 support (mostly); older versions may have issues
Yahoo Mail — Perfect UTF-8 support
Samsung Mail — Perfect UTF-8 support
Lotus Notes (legacy) — Variable; may auto-convert to ASCII or show mojibake
Corporate gateways — May re-encode to ASCII-only or apply QP

Fallback Strategy for Mixed Audiences:

Use UTF-8 as primary (all modern clients)
Test in legacy/corporate systems if known to be in audience
If issues appear, switch accented characters to ASCII equivalents (café → cafe)
For critical transactional emails with international users: provide ASCII-safe versions

Fallback Character Replacement

For critical emails (receipts, legal documents, password resets) sent to mixed international/corporate audiences, provide ASCII-safe fallback text.

ASCII Replacement Mapping:

é, è, ê, ë → e
á, à, â, ä → a
ó, ò, ô, ö → o
í, ì, î, ï → i
ú, ù, û, ü → u
ñ → n
ç → c
Emoji → [emoji description or remove]
— (em-dash) → - (hyphen)
"" (smart quotes) → "" (straight quotes)

ASCII Fallback Example (Transactional):


UTF-8 Version: "Merci! Your café order for José García"
ASCII Version: "Merci! Your cafe order for Jose Garcia"

Both convey the message, ASCII is universally readable

Email Character Encoding Checklist:

☐ Declared `Content-Type: text/html; charset=UTF-8` in headers
☐ Added `` in HTML ``
☐ Saved template file as UTF-8 (not ASCII, not Latin1)
☐ No BOM (Byte Order Mark) at file start
☐ No invisible control characters
☐ Used either Unicode OR HTML entities consistently (not mixed)
☐ Tested in Gmail, Apple Mail, Outlook
☐ If international audience: tested with accented characters
☐ If corporate audience: verified no mojibake/encoding issues
☐ If critical email: provided ASCII fallback version