The Importance of Content-Type HTML Character Encoding in Email


There have been many questions raised by our followers and subscribers 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 display, especially with respect to special characters in non-Latin languages or when copying from a text editor like Microsoft Word.

In short, 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 server sending your email will automatically set the character type value within the header. You can change this value 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’ve created a free online tool to help you in that process.

Try the Character Converter

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.

Setting the content-type is also important for email accessibility; it ensures nothing breaks the reading pattern for a subscriber, whether the subscriber is reading the email herself or using a screen reader.

Within Campaign Precheck’s accessibility workflow, you can set your email content-type with the click of a button. We’ll make sure the right code is added to your HTML.

content-type tool
Campaign Precheck’s content-type tool.


Where Does This Fit into HTML Emails?

In website development, we can specify the character set in a meta tag using this code:

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

Email clients display emails using the same premise; it will display the email based on the content-type. However, email clients read the content-type value set in the email header and they ignore the meta tag within the HTML.

How to Set the Content-Type in the Email Header

The server sending the email sets the header content. The header contains information like who is receiving the email (“to”), who is sending the email (“from”), date and time. Users can see some of this information at the top of each message 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

We sent the above code example in an email test to all the email clients Email on Acid supports. Nearly 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, regardless of what you set in the header.

Here are the test results:

Clients Content-Type
Outlook 2003, 2007 and 2010
Lotus Notes 8 and 8.5
iPhone Mail
Android Mail
Takes the content-type from the header of your email
Android Gmail
iPhone Gmail
iPad Gmail
Converts the content-type to UTF-8

One interesting action we noticed: The web-based clients convert your text to the content-type character set before displaying it in the browser. We were 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

Because email service providers (ESPs)  set content-type in the header, we have another layer of complexity added to our email development. Here are a couple of ways to tackle this:

Option 1:
Contact your email service provider (ESP) 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 you with 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.

Final Words on Content-Type

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

When you send an email test through Email on Acid, our servers are configured to send your email using the UTF-8 Content-Type to each of our supported email clients.

Whether you’re making design changes to your email, changing your content-type, or adjusting the way you encode HTML characters, all of it can have a big effect on how your email renders. That’s why it’s crucial to test and preview your email before each send. Want to see for yourself? Give our free trial a shot and see how we can help you streamline your email QA process.

Try it Today

This post was updated on January 25, 2019. It was last updated in February 2017 and first published in 2011.
Author: John Thies

John Thies is the CEO and Co-Founder of Email on Acid, a pre-deployment Email QA platform that strives to remove the inherent fear of hitting the "Send Button". He’s a passionate and engaging industry leader who lives, breathes, and dreams in email (seriously). John also serves as the CEO of Cause for Awareness, a recently formed non-profit that empowers other non-profit organizations with digital marketing resources. He resides in Denver, Colorado with his wife and son.

Author: John Thies

John Thies is the CEO and Co-Founder of Email on Acid, a pre-deployment Email QA platform that strives to remove the inherent fear of hitting the "Send Button". He’s a passionate and engaging industry leader who lives, breathes, and dreams in email (seriously). John also serves as the CEO of Cause for Awareness, a recently formed non-profit that empowers other non-profit organizations with digital marketing resources. He resides in Denver, Colorado with his wife and son.

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

  1. This is the kind of help we dream about. Thanks for this helpful and informative explanation of the real deal.

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

  3. Thank you!

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


  4. Great piece of info! It’s quite impressive post. Love this explanation. 🙂 Thanks for this allocation.

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

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

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

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

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


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

  11. Thanks for article and comments, we understood that we were using a wrong encoding when sending out our emails.

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

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

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

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

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

Comments are closed.