fix garbled text in email: character encoding errors explained
Garbled email text is almost always a character encoding mismatch. Here's how to fix it in your client, at the server level, and in automated pipelines.
You opened an email and saw é where there should be an é. Or ’ instead of an apostrophe. Maybe entire sentences are unreadable, and you're staring at a wall of symbols wondering if the sender had a stroke or if your computer did.
This is mojibake. It happens when the sending system encodes text in one character set and the receiving system decodes it in another. The bytes are the same; the interpretation is different. And it's one of the most common, most annoying problems in email.
The fix depends on where the mismatch occurred. If you're reading a garbled email right now, the steps below will help. If you're sending email from an automated pipeline or an AI agent, I'll show you how to prevent this at the infrastructure level so it never reaches a recipient's inbox.
LobsterMail enforces UTF-8 with correct MIME headers on every outbound message, so recipients never see garbled characters. and encoding is handled from the start.
How to fix garbled text in email#
- Check whether the garbling shows symbols (like
éor’) or question marks (?or�). Symbols are recoverable; question marks usually mean data was permanently lost. - Open the garbled email and manually switch the character encoding to UTF-8 in your mail client's View or Encoding menu.
- If switching to UTF-8 doesn't work, try ISO-8859-1, Windows-1252, or the encoding that matches the sender's language (Shift-JIS for Japanese, GBK for Chinese).
- Copy the garbled text into a tool like Notepad++ or fixgarbled.com and cycle through encodings until it renders correctly.
- Set UTF-8 as the default outbound encoding in your email client settings to prevent sending garbled text yourself.
- For server-side or API-sent mail, verify that your
Content-Typeheader declarescharset=utf-8and that the actual bytes match. - If you're building an email pipeline, validate encoding before delivery by checking that every string is valid UTF-8 before it hits the SMTP layer.
That list covers the full range, from "I received a broken email this morning" to "I'm building a transactional pipeline and want to get it right." The rest of this article explains why each step matters.
What causes garbled text in email#
Character encoding is the mapping between bytes and the characters they represent. The letter é is a single byte (0xE9) in ISO-8859-1 but two bytes (0xC3 0xA9) in UTF-8. When a mail server or client interprets those two UTF-8 bytes as two separate ISO-8859-1 characters, you get é instead of é.
This mismatch can happen at several points in the delivery chain:
- The sender's mail client encodes the message in one charset but declares another (or declares nothing at all) in the MIME headers.
- A relay server transcodes the message body without updating the charset declaration.
- The recipient's mail client ignores the declared charset and applies a different default.
- An email template hard-codes
charset=iso-8859-1in the HTML<meta>tag while the transport layer wraps it in a UTF-8 MIME part, creating a conflict between the inner and outer declarations.
The symptoms tell you exactly what went wrong. é means the text was encoded as UTF-8 but read as ISO-8859-1 (or Windows-1252). é means the reverse happened. And ? or � means bytes were destroyed during transcoding, which is usually permanent.
UTF-8 vs. ISO-8859-1 vs. Windows-1252#
| Encoding | Character range | Common usage | Risk level |
|---|---|---|---|
| UTF-8 | All Unicode (1.1M+ characters) | Modern web, APIs, most new systems | None if declared correctly |
| ISO-8859-1 | 256 characters (Western European) | Legacy SMTP servers, older systems | Fails on emoji, CJK, many special chars |
| Windows-1252 | 256 characters (Microsoft superset) | Outlook, older Microsoft products | Often confused with ISO-8859-1 |
UTF-8 is the correct choice for any new system, full stop. It handles every language, every emoji, every special character. The problem is that email is not a new system. SMTP dates to 1982, and some mail transfer agents still default to ISO-8859-1 or US-ASCII. When a modern UTF-8 message passes through a legacy relay that assumes ISO-8859-1, characters break.
Windows-1252 deserves special attention because it occupies a confusing middle ground. It's nearly identical to ISO-8859-1 but adds curly quotes, typographic dashes, ellipses, and other special characters in the 0x80-0x9F range that ISO-8859-1 leaves undefined. Outlook historically defaults to Windows-1252. That's why an email can look perfect in Outlook but show garbled text in Gmail or Thunderbird: Outlook interprets the bytes one way, and everyone else interprets them another.
Fixing encoding in specific mail clients#
Outlook#
Go to File > Options > Advanced > International Options and set "Preferred encoding for outgoing messages" to Unicode (UTF-8). For a received garbled email, right-click the message body, select Encoding, and try UTF-8. Outlook for Mac doesn't expose this setting directly and generally follows the system locale.
Gmail#
Gmail forces UTF-8 on all outgoing mail and attempts to auto-detect encoding on inbound messages. If you see garbled text in Gmail, the sender's encoding declaration is wrong or missing. There's no manual encoding override in Gmail's web interface. Your best option is to copy the garbled text into fixgarbled.com or click the three dots and choose "Show original" to inspect the raw MIME headers.
Thunderbird#
Go to View > Text Encoding and select UTF-8 (or the correct encoding). To set the default permanently, go to Settings > General > Reading & Display and set "Default text encoding" to UTF-8.
Apple Mail#
Apple Mail auto-detects encoding and doesn't provide a manual override. If you consistently receive garbled text from one sender, the problem is on their end and you can't fix it client-side.
When garbled text can't be recovered#
Not all encoding errors are fixable, and knowing the difference saves you from wasting time.
If the garbled characters are wrong symbols (like é, ’, ü), the underlying bytes are intact. They're just being misinterpreted. Switching to the correct encoding in your client, or running the text through a mojibake decoder, will restore the original characters. This is the recoverable case.
Warning
If you see ?, ???, or � (the Unicode replacement character), the original bytes were destroyed during transcoding. A system encountered bytes it couldn't map to the target encoding and substituted a placeholder. Once those bytes are gone, no encoding switch will bring them back.
If you're debugging a pipeline and seeing question marks in delivered mail, the fix has to happen upstream. Something between your message composition and the recipient's inbox is doing a lossy conversion. Look at relay servers, transport agents, or any middleware that touches the message body.
Preventing encoding errors in automated email pipelines#
If you're sending email through an API, SMTP relay, or agent-driven pipeline, client-side fixes are irrelevant. You need to get the encoding right before the message leaves your system.
Three things must agree for encoding to work: the actual bytes of the message body, the Content-Type header's charset parameter, the HTML <meta charset> tag (if applicable), and the Content-Transfer-Encoding setting. If any of those conflict, some clients will show garbled text even though others render the same message correctly.
Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable For programmatically generated email, and especially content produced by a language model, validate that every string is valid UTF-8 before inserting it into the message body. LLMs occasionally produce malformed byte sequences when generating non-ASCII characters, particularly in multilingual contexts. Those sequences survive string concatenation but break at the SMTP layer, sometimes silently.
If you're building an agent that sends transactional email, encoding is one of many infrastructure details that can silently degrade your email deliverability. SPF records, DKIM signing, encoding, MIME structure: none of these are hard individually, but they compound. That's why we built LobsterMail to handle all of them at the infrastructure layer.
For a practical example, see our guide on how to build a support agent that handles email, where encoding, headers, and deliverability are handled by the infrastructure so the agent focuses on responding to people instead of debugging charset declarations.
The MIME headers that control encoding#
Every email is a MIME document. The Content-Type header on each MIME part declares the charset:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
For multipart messages (which include both a plain-text part and an HTML part), each section has its own Content-Type. A common failure mode: the HTML part declares charset=utf-8 but the plain-text part inherits the server default of charset=us-ascii. Clients that prefer the plain-text view (some mobile clients, accessibility tools) will garble any non-ASCII characters even though the HTML version looks fine.
Content-Transfer-Encoding matters too. The options are 7bit, 8bit, quoted-printable, and base64. For UTF-8 text with non-ASCII characters, quoted-printable is the safest because it encodes non-ASCII bytes while keeping ASCII human-readable. 8bit works if every relay in the chain supports 8BITMIME (most modern ones do), but a single legacy relay that doesn't will corrupt the payload without warning.
Set both headers explicitly on every MIME part. Never rely on server defaults. The five minutes you spend getting this right prevents hours of debugging garbled text in production.
Frequently asked questions
What is email character encoding and why does a mismatch cause garbled text?
Character encoding maps bytes to characters. When the sender encodes text as UTF-8 but the receiver reads it as ISO-8859-1 (or vice versa), each byte gets mapped to the wrong character. The result is garbled symbols instead of the intended text.
What is the practical difference between UTF-8, ISO-8859-1, and Windows-1252 in email?
UTF-8 supports all Unicode characters and is the modern standard. ISO-8859-1 covers 256 Western European characters. Windows-1252 is Microsoft's superset of ISO-8859-1 that adds curly quotes and typographic characters. Use UTF-8 for anything built today.
Why do I see symbols like é or ’ in received emails?
Those patterns mean UTF-8 text was decoded as ISO-8859-1 or Windows-1252. The bytes are intact, so switching your client's encoding to UTF-8 or pasting the text into a mojibake decoder like fixgarbled.com should restore the original characters.
What is mojibake and how does it occur in email delivery?
Mojibake is the Japanese term for garbled text caused by character encoding mismatches. In email, it happens when the sending server, a relay, or the receiving client applies a different encoding than the one used to compose the message.
How do I change character encoding in Outlook?
For outgoing mail: File > Options > Advanced > International Options, then set preferred encoding to Unicode (UTF-8). For a received garbled message: right-click the body, select Encoding, and choose UTF-8 or the appropriate charset.
Can garbled email text be recovered when characters show as question marks?
Usually not. Question marks (? or �) mean the original bytes were destroyed during transcoding. This data loss is permanent. If you see wrong symbols like é instead, those are recoverable by switching to the correct encoding.
Why does an email look fine in Gmail but garbled in Outlook?
Gmail aggressively auto-detects encoding and compensates for mislabeled charsets. Outlook relies more heavily on the declared Content-Type header and falls back to Windows-1252 when the declaration looks untrustworthy. The email's encoding metadata is likely wrong, but Gmail hides the problem while Outlook exposes it.
What MIME headers control character encoding in an email?
The Content-Type header's charset parameter (e.g., charset=utf-8) declares the encoding for each MIME part. The Content-Transfer-Encoding header (quoted-printable or base64) determines how non-ASCII bytes are transported. Both should be set explicitly on every part of a multipart message.
How do I enforce UTF-8 encoding when sending email through an API or SMTP relay?
Set Content-Type to include charset=utf-8, use quoted-printable or base64 for Content-Transfer-Encoding, match any HTML meta charset tags to the MIME declaration, and validate that your message body bytes are actually valid UTF-8 before sending.
How can I prevent encoding errors in agent-generated or automated email?
Validate every string as valid UTF-8 before inserting it into the message body. Set explicit charset declarations on all MIME parts. Test with Outlook since it's the strictest client. Or use infrastructure like LobsterMail that enforces correct encoding automatically.
What is Content-Transfer-Encoding and which setting should I use?
Content-Transfer-Encoding specifies how the message body is encoded for SMTP transport. For UTF-8 content, quoted-printable is the safest option because it works with older relays. base64 also works but makes raw messages unreadable. Avoid 7bit for anything containing non-ASCII characters.
How do I stop outgoing emails from showing garbled characters to recipients?
Set your mail client's default outbound encoding to UTF-8. If you're sending programmatically, declare charset=utf-8 in both the MIME Content-Type header and any HTML meta tags. Validate your content is valid UTF-8 before handing it to the mail server.
Does LobsterMail handle character encoding automatically?
Yes. Every outbound message sent through LobsterMail uses UTF-8 with correct MIME headers and Content-Transfer-Encoding. You don't need to configure charset settings or validate encoding manually. and encoding is handled from the first message.
