HTML Encoding for Email Newsletters
Why HTML Encoding Matters in Email
Email clients are not browsers. They strip, reinterpret, and mangle HTML in ways web developers never expect. A character that renders perfectly in Chrome can appear as a broken symbol in Outlook or become a garbled mess in Gmail.
HTML encoding — converting special characters into entity references like & or — — ensures your content survives whichever rendering engine the recipient's client uses. If you send newsletters without attention to encoding, you are gambling with your brand's professionalism on every send.
Characters That Break Without Encoding
The unsafe five
These characters have structural meaning in HTML and must always be encoded:
| Character | Entity | Why it breaks email |
|---|---|---|
& | & | Starts entity references; unencoded & causes parser errors |
< | < | Opens tags; can inject or break markup |
> | > | Closes tags; can truncate content |
" | " | Delimits attributes; breaks inline styles |
' | ' | Delimits attributes in XML-based clients |
Typography that vanishes
Smart quotes, em dashes, and ellipses often fail in plain-text email fallbacks or older clients. Encoding them explicitly guarantees rendering:
| Character | Named Entity | Decimal | Typical Use |
|---|---|---|---|
| — | — | — | Em dash in copy |
| – | – | – | En dash in ranges |
| " | “ / ” | “ / ” | Curly double quotes |
| ' | ‘ / ’ | ‘ / ’ | Curly single quotes |
| … | … | … | Ellipsis |
Some email clients render named entities fine; others choke on obscure ones. Decimal numeric entities are the safest bet for maximum compatibility.
Email-Specific Encoding Challenges
Subject lines break too
If your subject line contains an ampersand or emoji, encode it. Subject lines pass through SMTP headers, not just the HTML body. A bare & in a subject can truncate the line or display as garbled text depending on the mailing service's encoding logic.
URL parameters inside emails
Tracking links often contain & separators between query parameters. Inside an HTML email attribute, those ampersands must be encoded:
<!-- WRONG: bare ampersand in href -->
<a href="https://example.com/offer?utm_source=newsletter&utm_medium=email">Shop now</a>
<!-- CORRECT: encoded ampersands -->
<a href="https://example.com/offer?utm_source=newsletter&utm_medium=email">Shop now</a>
Most email service providers handle this automatically. If you inject raw URLs into templates yourself, encode them manually or use an HTML encoder tool.
Microsoft Outlook and Word HTML
Outlook uses Word's HTML rendering engine. It supports a limited entity set and silently drops anything it does not recognize. If you use ', Outlook 2016 may strip it entirely — prefer ' for apostrophes in Outlook-targeted emails.
Encoding Across Email Service Providers
| Provider | Auto-encodes output? | Handles named entities? | Notes |
|---|---|---|---|
| Mailchimp | Yes (mostly) | Yes | Double-encodes if you encode first — encode only raw data |
| SendGrid | Partial | Yes | Test dynamic template variables carefully |
| Campaign Monitor | Yes | Yes | Template language may interfere with entities |
| Postmark | No | Yes | You must encode content yourself before sending |
If your ESP auto-encodes, do not pre-encode your content — you will get double-encoded output like &amp; visible to recipients.
Practical Workflow
- Write content in plain text without any entity encoding
- Run it through an HTML encoder before pasting into your email template
- Encode URLs separately — ensure query parameter ampersands are encoded but the URL structure stays intact
- Test in multiple clients — at minimum: Gmail (web), Outlook (desktop), Apple Mail, and a mobile client
- Check the plain-text fallback — some clients strip entities entirely and serve plain text; make sure the content still reads well
Common Mistakes
- Double-encoding — encoding content that your ESP will encode again, producing visible
&in the email - Forgetting subject lines — unencoded special characters in subjects get mangled in transit
- Using named entities Outlook ignores — stick to numeric entities for maximum safety
- Encoding image URLs — encoding
&in<img src>can break image loading in some clients - Assuming emoji works everywhere — emoji requires UTF-8 encoding on both the sending server and the receiving client; test before relying on it
Key Takeaways
- Always encode the five unsafe characters (
& < > " ') in email HTML bodies - Use numeric entities (
—) over named ones (—) for Outlook compatibility - Encode query parameter ampersands in URLs but never double-encode
- Subject lines need encoding too — do not forget them
- Test in Outlook specifically — it drops entities it does not understand
- Know your ESP's auto-encoding behavior to avoid double-encoding
Related Guides
Try It Yourself
Encode your newsletter content safely with our free HTML Encoder/Decoder. Paste your copy, get properly encoded output, and paste it into your email template — one click, no signup.