What this RFC defines
RFC 2047 defines how non-ASCII characters can appear in email message headers. It introduces the encoded-word syntax (=?charset?encoding?text?=) that allows any Unicode character to be represented in a From:, Subject:, or other header field, even though the underlying SMTP protocol is 7-bit ASCII.
Where you see it in practice
When you receive an email with a Subject: that contains accented characters, emoji, or Chinese text, the encoded-word format from RFC 2047 is what made it possible to transit SMTP safely. A subject line like =?UTF-8?B?SGVsbG8gV29ybGQ=?= decodes to “Hello World” in base64 UTF-8. Email clients that incorrectly decode RFC 2047 headers display garbled characters in subject lines.
How it connects to other RFCs
RFC 2047 is part of the MIME suite. RFC 2231 extends RFC 2047’s approach to handle non-ASCII characters in Content-Type and Content-Disposition parameter values (like filenames). RFC 6532 provides a more modern approach for internationalized email that avoids encoded-words entirely by allowing native UTF-8 in headers.
Current status
RFC 2047 is a current standard, published November 1996. It remains widely deployed despite being considered verbose by modern standards. RFC 6532 provides a cleaner alternative for systems that support internationalized email end-to-end.
Encoded-word syntax
RFC 2047 defines how to encode non-ASCII characters in RFC 5322 header fields. The syntax is =?charset?encoding?data?= where charset is a MIME character set name (UTF-8, ISO-8859-1), encoding is Q (quoted-printable-like) or B (Base64), and data is the encoded bytes. A subject like “Café” in UTF-8 becomes =?UTF-8?Q?Caf=C3=A9?= or =?UTF-8?B?Q2Fmw6k=?=. This allows the message headers to remain 7-bit-ASCII while representing text in any language.
Where encoded-words appear
Encoded-words are permitted in From, To, Cc, Bcc, Reply-To display names, in the Subject header, and in comments and phrase text of structured headers. They are not permitted in the domain part of email addresses (that requires RFC 6531 SMTPUTF8), in Content-Type parameter values (that requires RFC 2231), or in unstructured headers like Received. Placement rules are subtle enough that many email libraries misplace encoded-words and produce headers that valid parsers reject. If a Subject looks like =?UTF-8?B?…?= raw text in an inbox, that means the client failed to decode.
Modern alternatives
RFC 2047 was designed for a 7-bit ASCII world. Since RFC 6532 (2012), internationalized email headers can carry UTF-8 directly when both endpoints support SMTPUTF8. In practice, however, RFC 2047 encoded-words remain the dominant mechanism because they work with any transport, while raw UTF-8 headers require full RFC 6531 support end-to-end. Any email library that generates outbound mail should still produce RFC 2047 encoded-words for non-ASCII header values, falling back gracefully rather than assuming UTF-8 support.
RFC 2047 (November 1996) defines the encoded-word syntax: how to embed non-ASCII characters in email headers when the transport is 7-bit only. Format: =?charset?encoding?encoded-text?=. Two encodings: B (base64) and Q (quoted-printable). Enables Subject lines, display names, and other header values to carry UTF-8, Latin-1, Japanese, and any charset content while remaining 7-bit safe. Alternative to RFC 6532 UTF-8 direct (which requires SMTPUTF8 negotiation). Universally supported; still emitted by most mail generators for compatibility.
RFC 2047 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Embed non-ASCII characters in email headers via 7-bit safe encoding |
| Format | =?charset?encoding?encoded-text?= |
| Encodings | B (base64) or Q (quoted-printable variant) |
| Alternative for SMTPUTF8 paths | RFC 6532 UTF-8 direct |
| Where used | Subject, From/To display names, comments, other unstructured header values |
| Not allowed in | addr-spec (email addresses), Message-ID, Received, dates |
| Published | November 1996 |
Encoded-word syntax breakdown
B vs Q encoding: choosing between them
| Aspect | B (base64) | Q (quoted-printable) |
|---|---|---|
| Overhead | ~33% fixed | Variable; less for mostly-ASCII, more for heavy non-ASCII |
| Human readability | Opaque (base64) | Partial (ASCII characters visible) |
| Best for | Heavily non-ASCII content (Asian scripts, Cyrillic) | Mostly-ASCII with occasional non-ASCII (Latin extended) |
| Example content type | Chinese, Japanese, Arabic Subject lines | French, German, Spanish Subject lines |
Placement and combination rules
Header examples with encoded-word
Common encoded-word mistakes
=?utf-8?B?dXNlcg==?=@example.com is malformed; the parser sees =?utf-8?B?dXNlcg==?= as a local-part, which fails validation. For non-ASCII local-parts, use SMTPUTF8; there is no encoded-word alternative for addresses.Related standards and further reading
- Content-Type and MIME Structure: body-side encoding
- RFC 5322 Guide: header context for encoded-word
Frequently asked questions
Should I still use encoded-word in 2026 or move to RFC 6532 UTF-8 direct?
Both remain valid. Encoded-word is universally supported and works over any 7-bit or 8-bit path. RFC 6532 UTF-8 direct requires SMTPUTF8 negotiation. Modern mail libraries typically emit encoded-word for maximum compatibility while accepting either form inbound. If your entire path (sender + relays + receiver) supports SMTPUTF8, UTF-8 direct is cleaner; otherwise encoded-word remains the safe choice.
Why does Q encoding use underscore for space?
Historical shortening: quoted-printable’s =20 for space would triple the size of headers full of spaces (typical for display names and Subject lines). Underscore is defined as space in Q encoding specifically to keep encoded headers readable and compact. This means literal underscores in original text must be encoded as =5F in Q encoding; a common mistake is to emit literal underscore for a real underscore character.
Can encoded-word contain multiple charsets in one header?
Yes; each encoded-word declares its own charset. Adjacent encoded-words with different charsets are legal. However, some parsers handle transitions imperfectly, so consistent charset per header is safer. If you must mix (e.g., Japanese subject with embedded Latin quote), separate the different-charset segments with literal ASCII whitespace to help parsers.
What is the maximum length of an encoded-word?
75 characters total including the =?...?= markers. For longer content, split into multiple encoded-words separated by folding whitespace (CRLF followed by tab or space). Splitting must fall on charset boundaries (not mid-character in the original text). Most libraries handle this automatically; hand-written encoded-word generation frequently exceeds the limit and produces messages that strict parsers reject.
Can I use encoded-word in the local-part of an email address?
No. RFC 2047 explicitly prohibits encoded-word inside addr-spec. For non-ASCII local-parts, use SMTPUTF8 with UTF-8 addresses directly. For legacy 7-bit-only paths, there is no way to represent non-ASCII local-parts; delivery fails or requires ASCII aliases. For the domain part, use IDNA Punycode encoding (xn-- ASCII form).
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
