Preview your email in the most popular email clients and mobile devices.    Try it for FREE!

The Importance of Content-Type Character Encoding in HTML Emails

Posted December 17, 2010 by John Thies

Email Testing RSS Feed Email Test on Twitter Email CSS on Linked In Email Simulator on Stumbled Upon

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.  We will be adding an option for selecting your Content-Type in the near future.


Joel pic
This is the kind of help we dream about. Thanks for this helpful and informative explanation of the real deal.
Posted 01/04/2011

Cellarmasters eCommerce Team pic
Cellarmasters eCommerce Team
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,
Posted 09/06/2011

Azhar pic
Very useful info..Thanks for the detailed explantion
Posted 11/16/2011

ChrisH pic
Thank you!

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

Posted 02/21/2012

Nil jhonson pic
Nil jhonson
Great piece of info! It's quite impressive post. Love this explanation. smile Thanks for this allocation.
Posted 02/29/2012

alex pic
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.
Posted 03/04/2012

yash pic
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.!!
Posted 04/04/2012

Mau pic
Thanks a lot for this info pal! It was driving me nuts.
Posted 11/08/2012

Marcus pic
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!
Posted 06/25/2013

Ednei pic
Tks! This article save my time a lot!!!
Posted 01/07/2014

Ravi Iyer pic
Ravi Iyer
Thanks for the article..Would using UTF-8 help us in inbox deliveries?
Posted 02/10/2014

Terri pic
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.
Posted 02/14/2014

Amit Srivastava pic
Amit Srivastava
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.

Posted 05/16/2014

maha pic
how to remove that content type meta information in mail body
Posted 06/30/2014

Johnb987 pic
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
Posted 10/14/2014

JJ pic
This info is fantastic, thanks a lot

Posted 01/18/2015

Jessica Nordman pic
Jessica Nordman
Thanks for article and comments, we understood that we were using a wrong encoding when sending out our emails.
Posted 02/14/2015

Comment via our Blog



Remember my personal information
Notify me of follow-up comments?

Please enter the word you see in the image below:

Sign up for our Newsletter

And get updates on the latest email tips, tricks and hacks!