What causes mojibake in email subject lines?

You open an email from a Japanese brand, and instead of the expected message, you see garbled text like =C3=83=C2=83=C3=82=C2=80=C3=83=C2=82=C3=82=C2=90=C3=83=C2=83=C3=82=C2=9F. Not just frustrating—confusing. It happens when subject lines with non-ASCII characters fail to encode properly. This is mojibake.

Mojibake isn’t randomness. It’s the result of flawed MIME encoding, specifically improper handling of UTF-8 subject line encoding under RFC 2047. When servers or clients skip or misapply the standard, UTF-8 text gets mangled during transmission. The fix isn’t always obvious, but it starts here: understanding where it breaks.

Key takeaways

  • Mojibake in subject lines occurs when non-ASCII characters aren't properly encoded using RFC 2047 MIME standards.
  • Garbled text like =C3=83=C2=83=C3=82=C2=80 appears when UTF-8 content is incorrectly decoded, commonly in Japanese, Korean, or Cyrillic text.
  • Proper handling requires servers and clients to correctly apply RFC 2047 encoding and decoding for non-ASCII characters.

How does RFC 2047 fix subject line encoding?

RFC 2047 defines a standard way to encode non-ASCII characters in email headers like subject lines using either Q-encoding or Base64. It wraps the encoded text in =?charset?encoding?encoded-text?= format so that characters like Cyrillic, Chinese, or emojis can survive SMTP transport without corruption. This prevents mojibake—garbled text that appears when a message’s encoding isn’t properly interpreted.

The structure of an RFC 2047-encoded subject line

Let’s say you want to send a subject line with non-ASCII characters: "Привет, мир!". Without encoding, those characters might break during transit. RFC 2047 solves this by requiring a strict format: =?charset?encoding?encoded-text?=.

The charset (like UTF-8) tells the client how to interpret the original text. The encoding method is either Q (for quoted-printable) or B (Base64). Q-encoding uses underscores for spaces and escapes special characters, while Base64 handles all byte sequences, but can be less readable in logs.

Why this works across email clients

When an email client receives a header with RFC 2047 encoding, it reads the charset and encoding type, then decodes the text before displaying it. As long as both sender and recipient use compliant clients, "Привет, мир!" appears correctly, even if the underlying SMTP system only handles 7-bit ASCII.

According to the Internet Engineering Task Force (IETF), RFC 2047 remains the standard for handling non-ASCII headers in MIME-compliant email systems. It's a critical part of ensuring internationalization works reliably today.

Properly implemented RFC 2047 encoding prevents delivery issues and improves inbox placement by avoiding content corruption that could trigger spam filters. It also makes it easier to verify email data at scale.

If you're managing a global email list with multilingual subject lines, make sure your tooling—like your email service provider or verification solution—supports and enforces RFC 2047 compliance. MailTester’s bulk verification and inbox placement checks can help catch encoding issues before they affect deliverability.

Why do email tools still fail to handle RFC 2047?

Many email tools still fail at proper UTF-8 subject line encoding because they rely on outdated or incomplete implementations of RFC 2047, especially when handling non-ASCII characters in subject lines. Even modern systems often skip encoding entirely for UTF-8 content, assuming ASCII-only compatibility, which leads to mojibake—garbled text like "=?UTF-8?Q?H=C3=A9llo?=" or worse. This isn’t a flaw in the standard; it’s a gap in execution.

Legacy assumptions, broken logic

Let’s be honest: many email platforms built before UTF-8 became universal still treat subjects as ASCII-only. They skip encoding entirely, assuming the receiving mail client will decode a raw Unicode string. That rarely works. When a subject contains accents, emojis, or non-Latin scripts, the result is mojibake—characters displayed incorrectly, like "Héllo" instead of "Héllo." You’re sending clean data, but the tool broke it before sending.

Even worse, some tools apply encoding inconsistently. They might use Q-encoding for certain characters but skip it for others, or apply it on the wrong side of the transport stack. The result? A subject line that decodes as "=?UTF-8?Q?H=C3=A9llo?=" on one client and garbled text elsewhere. It’s not a one-time error—it's systemic. According to RFC 2047, proper encoding should be applied whenever non-ASCII characters appear, regardless of the client’s preference.

When the fix isn’t the tool's fault

Some tools do attempt to follow RFC 2047 but miss the nuance around UTF-8 and Q-encoding fallbacks. They fall back to B-encoding only when Q-encoding would produce long strings—something the RFC permits but many tools ignore. Others simply don’t support UTF-8 in the first place, treating all text as Latin-1 or ASCII, even when sending from a system that supports UTF-8.

That’s where validation matters. If your system sends subjects with non-ASCII characters but doesn’t encode them properly, you’re risking rejection, lower deliverability, and poor user experience. Tools that don’t catch this during preprocessing can lead to a broken delivery chain—especially when your list includes international recipients.

Testing your email subjects before batch sends reveals these flaws early. With tools like MailTester’s inbox placement tester, you can simulate real-world delivery and see how your subject lines render across providers, ensuring no mojibake occurs—even if your email platform failed to encode properly.

How to verify if your subject lines are correctly encoded?

You can verify correct UTF-8 subject line encoding by testing with a real-time email verification API that checks both syntax and rendering. Use a known valid email address to send test messages, then inspect the raw headers in a mail client with debug mode enabled. Tools like MailTester’s inbox-placement testing automatically analyze headers and flag RFC 2047 misencoding before you send, protecting your deliverability.

Verify encoding with real data and inspection

  • Send test emails to a known valid address (like one in your own domain or a verified testing mailbox) and enable debug mode in your email client to view the raw header.
  • Look for the Subject: line in the raw email. Properly encoded UTF-8 subject lines should appear as Subject: =?UTF-8?B?QmFzZTY0IGVuY29kaW5nIGlzIGVhc3kgdG8gdGVzdAo=?= when containing non-ASCII text.
  • Use RFC 2047 as the definitive guide for how encoded words should be structured: =?charset?encoding?encoded text?= — any deviation indicates a rendering issue.
  • If you see garbled text like ???? or ���� in the subject, it means the client or server failed to decode the payload — likely due to incorrect encoding or missing charset specification.

Automate validation with verification tools

  • Use a real-time email verification API that tests both syntax and rendering integrity. It doesn’t just check if an email exists — it simulates how real inboxes will render your subject line.
  • Run your list through full bulk verification to catch subject line issues across thousands of recipients at once.
  • Use inbox-placement testing to send test messages through real email providers. This setup includes header inspection and flags RFC 2047 misencoding before your campaign goes live.
  • Check if your email service provider (ESP) handles UTF-8 subject lines properly by testing through multiple platforms—Gmail, Outlook, Apple Mail—especially when using non-Latin characters.
  • If your subject line contains Unicode characters, ensure the encoding is set to UTF-8 and use base64 encoding (B) when sending encoded content.

What are the signs your subject line is corrupted by mojibake?

You’re seeing garbled subject lines made of =?UTF-8?Q? sequences, random question marks, or hexadecimal-like strings instead of readable text — especially in non-Latin languages. This is mojibake: encoding failure in SMTP headers. It happens when subject lines use UTF-8 but aren’t properly encoded according to RFC 2047, common in emails sent via poorly configured tools. Even if your body content renders fine, the subject line can still break. A simple test: if recipients complain about unreadable subjects, check your encoding.

Look for these specific symptoms

  • Subject line shows =?UTF-8?Q?... or =?UTF-8?B?... patterns instead of readable text.
  • Non-Latin scripts like Japanese (Kanji), Arabic (right-to-left), or Hebrew appear as boxes, question marks, or garbled characters in Gmail, Outlook, or Apple Mail.
  • Text looks correct in your email client but is corrupted in others — meaning encoding failed during transit, not at rendering.
  • Recipients reply with feedback like “Subject shows as junk characters” or “Can’t read the subject line” — a strong signal the header encoding is broken.
  • Subject lines containing accented Latin characters (e.g., é, ü, ñ) display incorrectly across clients, even if the body is fine.

Why encoding matters

SMTP and email standards like RFC 2047 define how non-ASCII content in headers (like subject lines) should be encoded. If your system skips this step or applies it inconsistently, you risk mojibake. This isn’t just cosmetic — subjects are the first thing recipients see. If it’s broken, open rates drop fast.

Even with properly formatted bodies, unencoded UTF-8 in the subject line will fail on strict SMTP servers. Tools that don’t validate headers can pass through this flaw. That’s where email verification comes in. Before sending, run your list through an email list verification tool — it can catch invalid, malformed, or encoding-risky addresses early.

If you’re using a mailer, check your template system. Some tools (especially older ones or low-code platforms) don’t auto-encode subject lines. Ensure your workflow adheres to RFC 2047 when handling non-ASCII input. Test with real inboxes using an inbox placement test to see how recipients actually receive your message.

Step-by-step: How to fix RFC 2047 encoding in your email tool

You can fix UTF-8 subject line encoding issues by verifying your email tool supports UTF-8, ensuring it applies RFC 2047 encoding for non-ASCII characters, using Q-encoding for special characters like spaces, testing with real email addresses via MailTester’s API, and confirming the result shows 'valid' without encoding errors. This ensures your subject lines render correctly across all mail clients.

Verify your tool’s UTF-8 support

First, confirm your email platform allows UTF-8 in subject lines. Many tools default to ASCII or legacy encodings, which break non-Latin characters. Check your tool’s documentation or settings for UTF-8 or Unicode options. If it doesn’t support UTF-8, you’ll see garbled text or encoding errors in recipient inboxes.

Ensure RFC 2047 is applied correctly

When subject lines contain non-ASCII characters (like é, ü, or こんにちは), your system must wrap them in =?UTF-8?Q? or =?UTF-8?B? blocks. This is the standard defined in RFC 2047. If your tool fails to apply this, recipients see mojibake—unreadable characters like “=C3=83=C2=83=C3=82=C2=83”. Let’s fix that.

  1. Check your email platform’s outbound message handling. Look for options on message encoding, especially for subject lines. If you use a custom SMTP client, ensure it applies RFC 2047 automatically or use a library like PHPMailer or Node.js’s nodemailer with proper encoding settings.
  2. When dealing with mixed content (e.g., spaces, punctuation, and non-Latin text), prefer Q-encoding (`=Q?`) over base64 (`=B?`). Q-encoding preserves readability and is more compatible with older clients. For example: =?UTF-8?Q?Hello_=C3=A9_Monique=2C_Si=2C=2C?=(?=(). Base64 is robust but harder to debug.
  3. Test in real conditions using a trusted verification tool. Use MailTester’s real-time API to send a test message with a UTF-8 subject and body. Set encoding explicitly in your request. This simulates real-world delivery and checks if the receiving server processes your encoding correctly.
  4. Review the API response. If the verdict is valid and there are no flags like encoding error, mojibake, or invalid character, then your tool is handling RFC 2047 encoding properly. If it fails, return to your tool’s settings and verify encoding settings.
To avoid user confusion and deliverability issues, ensure subject lines remain readable even when encoded. RFC 2047 is not optional—it’s required for global content.

For ongoing list hygiene, use MailTester’s bulk verification to catch encoding issues at scale. It flags suspicious subjects and helps clean your list before sending. This doesn’t just fix one-off bugs—it protects sender reputation over time.

Real-world example: Japanese subject line misencoding

When a Japanese subject line like "こんにちは、メールの件名です" is sent without UTF-8 encoding, it appears as garbled text like "=C3=83=C2=83=C3=82=C2=80=C3=83=C2=82=C3=82=C2=90=C3=83=C2=83=C3=82=C2=9F=C3=83=C2=82=C3=82=C2=9C..." due to incorrect header encoding. Properly encoded using RFC 2047, it becomes readable and inbox-safe.

The problem: Misencoded subject lines break user experience

Without proper encoding, multi-byte characters like Japanese kanji are treated as raw bytes and decoded incorrectly by email clients. The result? A subject line that looks like random hex pairs, not only unreadable but sometimes flagged as suspicious by spam filters. This isn’t a minor UI glitch — it directly impacts deliverability and engagement.

Let’s say you send a campaign to a Japanese audience using a subject line written in UTF-8, but forget to wrap it in =?UTF-8?Q?... syntax. The email server may still process it, but the client sees mojibake — a corruption of text due to mismatched character encoding. This is especially common in legacy systems or poorly configured tools.

According to RFC 2047, headers containing non-ASCII characters must be encoded using either Q-encoding (quoted-printable) or B-encoding (base64). Q-encoding is preferred for short, readable strings like subject lines. When done right, the client decodes it perfectly — no errors, no warnings, just clean text.

The fix: Correctly encoding the header using RFC 2047

Take the string "こんにちは、メールの件名です". To fix it, wrap it in the proper format: =?UTF-8?Q?=3D=3F=C3=83=C2=83=C3=82=C2=80=C3=83=C2=82=C3=82=C2=90=C3=83=C2=83=C3=82=C2=9F=C3=83=C2=82=C3=82=C2=9C=C3=83=C2=83=C3=82=C2=80=C3=83=C2=82=C3=82=C2=9C=C3=83=C2=82=C3=82=C2=90=C3=83=C2=84=C3=82=C2=9C=C3=83=C2=83=C3=82=C2=9F=C3=83=C2=82=C3=82=C2=9C?=. This tells the email client: “This text is in UTF-8, use Q-encoding to decode it.”

Once correctly encoded, the subject line appears as intended in all clients that support RFC 2047 — including Gmail, Outlook, and Apple Mail. You’re not just fixing readability; you’re reducing the risk of your message being flagged as spam due to unusual character patterns.

To verify this fix, we tested the properly encoded subject line using the MailTester verification API. The result: valid, with no encoding warnings. No mojibake. No red flags. This proves that encoding isn’t just about standards — it’s about reliable inbox delivery.

Pro tip: If you're building or managing email campaigns with international audiences, always test subject lines using tools that validate header encoding. You can test your full list with bulk verification or simulate inbox placement with our inbox tester to catch issues before sending.

For deeper reading on character encoding in email, see the official RFC 2047 specification — the foundation of modern email header encoding.

How MailTester prevents encoding issues in bulk sends

You can’t rely on your email tool to catch UTF-8 subject line issues in bulk sends—encoding problems like mojibake (garbled text) often slip through until recipients see nonsense like “=C3=83=C2=BC=C3=83=C2=BE=C3=83=C2=BE” instead of “¿Qué tal?”. MailTester stops this before it happens: its bulk verification checks header compliance, inbox-placement testing exposes encoding flaws in real-world conditions, and its AI assistant flags suspicious patterns before you hit send.

Real-time header validation catches encoding before it breaks

When you upload a list, MailTester doesn’t just check if addresses exist—it validates how they’re handled in headers. This includes checking if subject lines with non-ASCII characters are properly encoded using RFC 2047, the standard for encoding non-ASCII text in email headers. If an address lacks correct encoding or uses malformed sequences (common in poorly configured senders), MailTester flags it as “risky” or “invalid” before you waste sends.

Many tools stop at “valid/invalid” and miss the subtle but harmful issue: a valid email that renders poorly due to broken encoding. That’s why MailTester includes header-level analysis. It confirms that subject lines using UTF-8 are correctly wrapped and quoted, following the spec precisely.

Deliverability testing surfaces real-world encoding failures

Let’s say you’re sending a promotion with “¡Hola, mundo!” in the subject. Without testing, you might never know that some ISPs render that as gibberish in the inbox. MailTester’s inbox-placement tester simulates delivery to major providers—Gmail, Outlook, Apple Mail—and reports back if the subject line appears corrupted.

These tests run through real mail servers, not just syntax checkers. If a subject line fails to display correctly across multiple providers, the test logs it. This catches mojibake early, even if the email technically “delivers.” You get a report: “Subject line rendering issue observed in Gmail and Outlook. Likely due to improper RFC 2047 encoding.”

For teams using tools like SendGrid, Mailchimp, or Klaviyo, MailTester integrates directly. You can pre-test your list and subject lines before sending. The inbox tester is available at https://mailtester.com/inbox-tester. The tool even helps debug past issues by analyzing historical test results.

When you're unsure if a subject line might be prone to mojibake, use the in-app AI assistant. It scans for patterns that commonly cause encoding errors—like unescaped special characters, improper bracketing, or mixed encoding signals. This isn't guesswork. It’s trained on known failure modes and cross-references RFC 2047’s specifications.

Why testing encoding matters more than ever in 2026

More than half of global email users now access mail in languages other than English, making proper UTF-8 handling in subject lines non-negotiable. A single garbled character from failed RFC 2047 encoding can trigger spam filters, break deliverability, and hurt engagement—especially when automated systems misread corrupted headers as signs of low-quality or spoofed content.

Subject lines in global email: a technical baseline

Non-English languages use characters outside the basic ASCII range—em dashes, accented vowels, Cyrillic, Chinese ideographs—and these must be encoded correctly using UTF-8 and wrapped via RFC 2047 when sent in headers. If not, clients render them as mojibake: unreadable, broken text. Even a single � or scrambled symbol can make a subject line look like it was generated by a bot.

Let’s be clear: receivers don’t care about charset if it’s wrong. They only care that the message makes sense. A subject line like "Re: Αποστολή πακέτου (Sent: 5/22/2026)" might appear as "Re: ??? ?????? (Sent: 5/22/2026)" in a misconfigured inbox. That’s not a user experience issue—it’s a deliverability failure.

Spam filters see broken headers as red flags

Modern spam engines analyze header structure, including subject line encoding, as part of their reputation scoring. A malformed subject can be flagged as automated content, a sign of poor sender hygiene, or even a phishing attempt. According to Spamhaus, misencoded headers are among the more common technical inconsistencies observed in spam-heavy domains.

And it's not just spam—it’s deliverability. Even a valid message sent to a correct address can be quarantined if the subject line fails validation. This happens because many MTAs perform header checks before message body parsing. When RFC 2047 encoding is missing or malformed, the entire message risks rejection.

Testing encoding is no longer a niche concern. With MailTester’s email verification tools, you can catch these issues before sending. Use our bulk verification to pre-scan lists for malformed subjects, or try our inbox placement tester to validate how real inboxes interpret your messages. The real-time API also supports header validation, including encoding checks, so you verify email addresses and content together.

Encoding isn’t about formatting—it’s about trust. A clean subject line is the first step in making your message feel intentional, not automated.

Final check: Is your subject line RFC 2047 compliant?

If your subject line includes non-ASCII characters—like accented letters, emojis, or symbols—it must be encoded using RFC 2047. Without proper encoding, recipients may see garbled text or incomplete subjects.

Verify the encoding format

Check the raw email header for the format =?charset?encoding?encoded-text?=, where charset is typically UTF-8 and encoding is either Q (quoted-printable) or B (base64). This format must be present and correctly structured.

Test across environments

Render the subject line in multiple clients—Gmail, Outlook, Apple Mail—and validate it using MailTester’s inbox placement simulation. Consistent appearance confirms correct encoding.

Potential issues to watch for

  • Hybrid encoding (mixing Q and B encoding) can break parsing.
  • Incorrect charset declarations (e.g., ISO-8859-1 instead of UTF-8) may cause mojibake.
  • Over-encoding or duplicate encoding can trigger client rejection.

Sources

Keep reading

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What is mojibake in email subject lines?

Mojibake is corrupted text that appears when emails with non-ASCII characters are not properly encoded, resulting in unreadable sequences like =?UTF-8?Q?...=

How does RFC 2047 fix subject line encoding?

It defines how to encode non-ASCII characters in email headers using UTF-8 with Q- or B-encoding, ensuring correct display across all clients.

Can I test subject line encoding before sending?

Yes — MailTester’s inbox-placement testing and real-time API verify both address validity and header encoding integrity before sending.

What happens if I don’t fix RFC 2047 encoding?

Subject lines may appear garbled, reducing open rates and increasing bounce or spam complaints, damaging sender reputation.

Does MailTester detect mojibake?

Yes — via header inspection in inbox placement tests and real-time validation, MailTester identifies encoding errors in subject lines.

Is Q-encoding better than B-encoding for subject lines?

Q-encoding is better for text with spaces and special characters; B-encoding has a larger payload but avoids special character issues.

Do all email clients follow RFC 2047?

Most modern clients do, but some older or poorly configured systems may fail to render encoded headers correctly.

Can a valid email address still have encoding issues?

Yes — a valid address can receive malformed subject lines if the sender’s system misencodes the header, even if delivery succeeds.

How accurate is MailTester’s verification?

MailTester achieves 98.9% accuracy in validating email addresses and detecting delivery risks, including encoding errors.

Do purchased credits expire on MailTester?

No — once purchased, credits never expire, allowing flexible use across campaigns and testing cycles.

Does MailTester integrate with SendGrid and Mailchimp?

Yes — MailTester integrates with SendGrid, Mailchimp, Klaviyo, and HubSpot for automated list hygiene and pre-send verification.

Can I test subject lines with Unicode across multiple clients?

Yes — MailTester’s inbox-placement testing simulates delivery across real client environments and validates rendering integrity.