Click to Sign Up for a 7 Day Free Trial!

Email Development

The Importance of Content-Type HTML Character Encoding in Email

Email On Acid

There have been many questions raised by our members on how email clients set the Content-Type within their HTML emails. As you may already know, the Content-Type plays a major role in the way an email will be displayed, especially with respect to special characters in non-Latin languages or when copying from a text editor like Microsoft Word.

In summary, all email clients ignore the Content-Type defined within your meta tag. Instead, they read it from the Content-Type value that is in the header of your email. The character type value within the header is automatically set by the server sending your email. This value can be changed but you would need direct access to the email server. The safest solution is to convert all of your special characters to HTML entities and we have created a free online tool to help assist you in that process.

What is Content-Type?

A Content-Type tells the web browser or email application how to interpret the text characters in your HTML or the body of the email. The most popular character sets are UTF-8 and ISO-8859-1.

To illustrate, let's take the following code:

<p>UTF-8 Characters: ö ü ä</p>
<p>UTF-8 Chinese: 激 光 這 </p>
<p>HTML Entity Characters: &#28450; &#23383;</p>

Here's how it renders using each character set:

As you can see above, the Chinese symbols are not represented in the ISO-8859-1 character set. This is because ISO-8859-1 only includes Latin based language characters. The result is a bunch of jumbled text, which is the ISO-8859-1 interpretation of the symbols.

Where does this all fit into HTML emails?

In website development, we can tell the web browser what character set to use in a meta tag like this:

<meta http-equiv="Content-Type"  content="text/html charset=UTF-8" />

Emails are displayed in clients using the same premise. It will display the email based on what Content-Type has been set. However, email clients read the Content-Type value that is set in the email header and they completely ignore the META tag that is within the HTML.

How does the email header Content-Type get set?

The header content is set by the server sending the email and contains information like To, From, Date, Time, etc. Some of which is displayed at the top of each email when viewing it in an email client.

Here is a snippet of an email header (notice the Content-Type value):

Date: Wed, 15 Dec 2010 12:45:55 -0700
Subject: UTF-8
Message-ID: <>
X-Priority: 3
X-Mailer: EOAMailer 5.0.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset="UTF-8"

Email client test results

I sent the above code example to all the email clients that we support. Pretty much every client renders text based on the Content-Type value set in the email header. Gmail is the only client that automatically converts your text to UTF-8, no matter what the header Content-Type is set to.

Here are the test results:

Clients Content-Type
Outlook Express
Outlook 2003, 2007 and 2010
Lotus Notes 6.5, 7, 8 and 8.5
Live Mail
Windows Mail
Entourage 04 and 08
Yahoo Classic, Current, and Beta
Thunderbird 2 and 3
iPhone Mail
Android Mail
Each take the Content-Type from the header of your email
Android Gmail
iPhone Gmail
iPad Gmail
Each convert the Content-Type to UTF-8

One thing that I found very suprising is the fact that the web-based clients convert your text to the Content-Type character set prior to displaying it in the browser. I was able to check this by viewing what Content-Type they were setting in their META tags. As it turns out most of them are using UTF-8.

The Solution

Now you might be saying to yourself, great just when I thought designing emails wasn't complicated enough. It does in-fact add another layer of complexity but there are a couple fairly easy solutions.

Option 1:
Contact your email service provider and ask them what Content-Type they set in the header when sending the emails. Once you know the Content-Type use that value in your HTML Meta tag when designing the email.

Option 2:
Convert all special characters to their HTML entities and you won't have to worry about the header Content-Type. For example, the following character "" has an HTML entity value of "&#28450;". To help assist you in the conversion we have created a free online tool that will convert all of your special characters for you! Just use this conversion tool before you send your email.

In Conclusion

It is always important to check your character sets using both IE and Firefox, especially if you are using non-Latin characters or copy/pasting content from a text editor like Microsoft Word.

At this time, when you submit an Acid Test, our servers are configured to send your email using the UTF-8 Content-Type to each of our supported email clients.

Just like making any other changes to your email, changing your content-type or the way you encode HTML characters can have a big knock-on effect throughout the rest of the email. Make sure you're steering clear of any issues by testing for free with our 7 day trial of Email on Acid.

About the Author

John Thies

John Thies

John is the man behind the scenes who makes sure everything is running smoothly. He loves all things technology, from programming to tinkering with mobile devices to reading the latest issue of Wired magazine.

Join the Discussion

This is the kind of help we dream about. Thanks for this helpful and informative explanation of the real deal.
Hi, I have been trying to sent a question via the Contact Us section but I get an error stating I don't have authorisation. Please investigate.

Many thanks,
Cellarmasters eCommerce Team
Very useful info..Thanks for the detailed explantion
Thank you!

I've got to send some emails in 32 languages and was worrying about charset hassles.

Great piece of info! It's quite impressive post. Love this explanation. smile Thanks for this allocation.
Nil jhonson
After reading the article, I sent Chinese characters emails I've received with my aol webmail to a gmail account. Those characters that are wrongly display as ? in the aol webmail account still ends up as ? in the gmail account. Seems gmail is not the solution.
Hi, Everyone..
I am designing Pop3 client . I want character set of Body part. But in some cases for particular mail client I am getting nothing as a Charset value.
I am worried what character set to be consider.
from a mail client I am getting nothing as a character set value for any language body part.
Help me to decide character set.!!
Thanks a lot for this info pal! It was driving me nuts.
Ironically, this page's encoding is broken. Chinese characters are corrupted but accented latin ones are not, suggesting it's being delivered as ISO-8859-1 even though it's declaring UTF-8!
Tks! This article save my time a lot!!!
Thanks for the article..Would using UTF-8 help us in inbox deliveries?
Ravi Iyer
I've just run into this with a blast vendor requesting we encode all emails using Western(ISO Latin 1) which I discovered is ISO-8859-1. I had always used UTF-8 and honestly never thought that it could matter.

It's strange because I cannot use HTML entities with #'s for them like this: © I can only use the entity name © Otherwise when they send tests my symbols come up as ? or something else strange.

Thanks for this explanation.
I am using REST in my application which is using Content-Type:application/x-www-form-urlencoded;
When I am calling a post method in chrome its working fine , but when I am trying this in firefox.
An extra content type added like
Content-Type:application/x-www-form-urlencoded; charset=UTF-8;
And then POST service is not working as expected. So could you tell me what should I need to do.

Amit Srivastava
how to remove that content type meta information in mail body
Good post. I study something more challenging on completely different blogs everyday. It is going to all the time be stimulating to learn content material from different writers and practice somewhat one thing from their store. I ggddckfdkdgd
This info is fantastic, thanks a lot

Thanks for article and comments, we understood that we were using a wrong encoding when sending out our emails.
Jessica Nordman
To be clear: HTML entities, Hex and Decimal coded characters work regardless of content type?
Martijn, yes, that's right. They should work regardless of content type.
Geoff Phillips
Awesome post, thank you!
Thanks for this article. 6 years ago we did that wrong and receive emails with unreadable content. Do you have an idea how we can still read it?
EoA Character Encoder is not the best tool. Years ago I discovered that I actually need three tools in one: 1) HTML character encoder; 2) invisible character cleaner/remover; 3) English language style improvement tool. Ideally, in a shape of NPM package which I can use in Gulp, with optional front end, driven by browserified version of it. That's how came to life. As a critique point, EoA Character Encoder encodes emoji incorrectly, doesn't decode HTML and can't adjust between HTML or XHTML closing slashes on BR's. does all this. Another important point is, encoded entities should be named, not numeric, so you could read them. For example, £ is better than £ when you are checking text. That's another difference between and EoA Character Converter.
I didn't see Apple Mail/Mac Mail referenced in the list. One recipient gets mail at and reads it on his desktop through Apple/Mac mail. Do you know how that would handle content type?
Cheers for this article, big help!
I use Salesforce Email Studio (previously Exact Target). It does character conversion for you (inserts entities). The content type is set within HTML template (in the meta like for a web page; I believe this is for a web version of the email) and when building an email (this I believe is for the email header as you must set it regardless the meta in the template).
I tested that HTML entities do depend on the character set settings (aka Language settings / email header meta) so entities from outside a character standard/set won't show properly unless the character set is properly set up.
This still depends on the tool you use - there is no point in setting anything else but the UTF-8.

Leave a Comment