Why don't my international characters appear correctly in some clients?
Email clients can be a cause of pain when it comes to encoding. Luckily there's a fix that will work well for you to ensure your readers always see the correct character.
This article goes quite in depth into why character encoding doesn't always work as you'd expect. If you're looking for a quick fix, the answer is to use HTML entity names instead of using the problematic character directly within your HTML markup.
The most common mistake made is using UTF8 characters directly in the HTML markup of your email. You need to use HTML entity codes that correspond to the character within the UTF charset. This is the best practice and is considerably more robust than relying on your transfer encoding to deliver those characters without breaking them.
There's a full list of all UTF8 HTML entity codes here: https://www.w3schools.com/charsets/ref_utf_latin1_supplement.asp (use the options in the left-hand column to see more).
You can use either entity numbers, these correspond directly to the byte value of the UTF8 character. For example, a with a ring (å) may be represented as å because a byte value of 229 (11100101) is that character's binary value. Or you can use entity names (which are a little friendlier to work with). The entity name for a with a ring is aring, so you'd represent this in HTML as å
You can paste your copy (NOT your HTML markup, as more than (<) and less than (>) symbols will be converted into entity names) into this tool to have it automatically convert non-ASCII (7-bit) characters into HTML entity names: http://www.htmlescape.net/htmlescape_tool.html.
If you'd prefer to do this as you hit issues, simply replace any characters you have problems with, with its corresponding html entity name.
Litmus supports all language packs in modern webmail and desktop clients. Outlook 2003 and above support these characters. We also support all encodings, from ASCII (UTF7) to UTF32 for testing.