Why Are My Emails Showing Random Characters? Understanding Base64 & Quoted-Printable Encoding

1. The 7-Bit Problem: Origins of MIME Encoding

The roots of email encoding problems trace back to 1982, when RFC 822 first defined the standard for internet email messages. At that time, email was designed to transmit only 7-bit ASCII characters — a character set covering just 128 values (0–127).

This strict limitation existed for several technical and historical reasons:

• Early network hardware — modems, multiplexers, and terminal concentrators — was physically limited to 7-bit communication channels.
• The Simple Mail Transfer Protocol (SMTP), defined in RFC 821, was built on the assumption that only printable ASCII text would be transmitted.
• Characters in the 8-bit range (128–255) often got stripped or corrupted as intermediate relay servers interpreted them as control commands.
• Line lengths were restricted to under 1,000 characters per RFC specification.

As computing evolved globally, users needed to transmit binary files, international text with accented characters (é, ü, ñ), emoji, and rich HTML content via email — all of which require 8-bit bytes. When this 8-bit data passed through 7-bit-only relay systems, it became corrupted or unreadable.

2. What Is MIME?

MIME (Multipurpose Internet Mail Extensions), defined in RFC 2045–2049, is the standard that extended email to support non-ASCII content. It introduced content-type headers, multipart message structures, and — most importantly for this guide — content transfer encoding mechanisms.

A MIME-encoded email header looks like this:

The Content-Transfer-Encoding header tells the receiving email client how the message body has been encoded, so it knows how to decode it back to readable content.

3. Base64 Encoding: What It Is and How It Works

Base64 is a binary-to-text encoding scheme that converts arbitrary binary data into a string of 64 printable ASCII characters. The name comes from the fact that it uses a 64-character alphabet: A–Z, a–z, 0–9, plus + and /, with = as padding.

How Base64 Works

Base64 takes every 3 bytes of raw data (24 bits) and converts them into 4 ASCII characters (6 bits each). This means Base64-encoded content is approximately 33% larger than the original data.

When Base64 Is Used in Emails

• HTML email bodies — entire HTML content is often Base64-encoded
• Email attachments — images, PDFs, Word documents, ZIP files
• Subject lines with special characters — emoji, Unicode, non-Latin scripts
• "From" display names — when the sender name contains non-ASCII characters

4. Quoted-Printable Encoding Explained

Quoted-Printable (QP) encoding is defined in RFC 2045 Section 6.7. It was designed specifically for text that is mostly ASCII but contains occasional non-ASCII characters — making it far more efficient than Base64 for plain text content with only a few special characters.

How Quoted-Printable Works

In QP encoding, regular printable ASCII characters (33–126) are transmitted as-is. Only non-ASCII bytes, special characters, spaces at line ends, and long lines require encoding. Each non-ASCII byte is encoded as =XX where XX is its uppercase hexadecimal value.

Lines in QP encoding must not exceed 76 characters. If a line is too long, a soft line break (an = at the end of the line) is inserted, which the decoder ignores and treats as a continuation.

5. Base64 vs Quoted-Printable: When to Use Which

Choosing the right encoding for your emails has a direct impact on deliverability, readability in raw form, and bandwidth consumption. Here's a complete comparison:

6. Email Subject Line Encoding (RFC 2047)

Subject lines and "From" display names in emails follow a special encoding scheme called RFC 2047 encoded-words. This is because email headers are restricted to a subset of printable ASCII by RFC 822, but modern emails routinely contain emoji, accented characters, and non-Latin scripts in subjects.

The RFC 2047 encoded-word format is:

Where:

• charset — the character set (e.g., UTF-8, ISO-8859-1)
• encoding — either B for Base64 or Q for Quoted-Printable
• encoded_text — the actual encoded content

7. Practical Examples

Example 1: Plain ASCII Subject (No Encoding Needed)

When a subject line contains only printable ASCII characters, no encoding is required. The subject is transmitted exactly as written.

Example 2: Subject with Emoji (Base64)

Example 3: HTML Body with Quoted-Printable

Example 4: Image Attachment (Base64)

8. How to Decode Encoded Emails

When you receive an email and need to inspect its raw encoded content — for debugging, spam analysis, or email development — you need a decoding tool. Here's how to approach it:

Step 1: View the Raw Email Source

In Gmail, click the three-dot menu on an email → "Show original." In Outlook, open the email and press Ctrl+U (PC) or use File → Properties. This reveals all MIME headers and encoded content.

Step 2: Identify the Encoding

Look for the Content-Transfer-Encoding header. If it says base64, the body is Base64-encoded. If it says quoted-printable, use a QP decoder.

Step 3: Use a Decoding Tool

Use our free HTML Decoder tool to instantly convert Base64 or Quoted-Printable encoded email content back to readable HTML. For subject lines, use our Subject Encoder/Decoder which handles RFC 2047 encoded-words automatically.

9. Impact on Email Deliverability

Encoding choices directly affect whether your emails reach the inbox or the spam folder. Here's what major email service providers and spam filters look for:

What Spam Filters Check

• Encoding consistency: Does the declared Content-Transfer-Encoding match the actual encoding used in the body?
• Overuse of Base64: Spammers often use Base64 to obfuscate phishing links and malicious content. Some filters penalize purely Base64-encoded bodies.
• Character set mismatch: Declaring charset=UTF-8 but sending Latin-1 bytes triggers spam score increases.
• Invalid encoded-words: Malformed RFC 2047 subject lines (missing closing ?=, spaces inside encoded words) can trigger warnings.

Best Practices for Maximum Deliverability

• Always declare your Content-Transfer-Encoding header explicitly
• Use Quoted-Printable for text/ and text/html MIME parts
• Use Base64 only for binary attachments and non-ASCII subject lines
• Ensure your charset declaration matches the actual encoding of your content
• Keep subject lines under 78 characters total including encoded-word overhead
• Test encoded subjects across Gmail, Outlook, and Apple Mail before large sends

10. Conclusion & Best Practices

Email encoding is a fundamental — yet frequently misunderstood — aspect of modern email infrastructure. Understanding the difference between Base64 and Quoted-Printable, knowing when to use RFC 2047 subject encoding, and following MIME standards correctly are essential skills for any developer or email marketer building reliable, deliverable email campaigns.

In summary:

• ✅ Use Quoted-Printable for HTML and plain-text email bodies
• ✅ Use Base64 for binary attachments and emoji/non-ASCII subject lines
• ✅ Always declare Content-Transfer-Encoding and charset headers
• ✅ Validate encoded subjects with our encoder/decoder tool
• ✅ Test across multiple email clients before deploying at scale
• ❌ Never send binary content without encoding in an email body
• ❌ Do not use Base64 to "hide" content from spam filters — this backfires