Character Encoding

The Importance of Content-Type HTML Character Encoding in Email

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:

Rendering results with different sets

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:

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.


Author: Alex Ilhan

28 thoughts on “The Importance of Content-Type HTML Character Encoding in Email”

  1. 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,

  2. 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.

  3. 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.!!

  4. 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!

  5. 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.

  6. Hi,
    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.


  7. 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

  8. 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?

  9. 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.

  10. 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?

  11. 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.

  12. If email clients only pay attention to the content type set in th e header then how do they deal with multipart messages and in particular the different statements text/html and text/plain?
    How can one statement be a solution for all in multiparts?

    1. Hi Jon –

      Great question! There really is no *one* solution, but UTF-8 provides a solution for many. Per “The more widely a character encoding is used, the better the chance that a browser [or in this case, email] will understand it.”

      UTF-8 is a good choice because it can support several languages, which means it can accommodate pages and forms that may have a mixture of those languages. It also reduces complexity when dealing with a multilingual site or application, because it eliminates the need for server-side logic to individually determine the encoding for each page or form submission.

      More info is available here:

      I hope that helps! Thanks for reading.

Leave a Reply

Your email address will not be published. Required fields are marked *

Free Email Goodies