MIME Encoded-Word Decoder
Email subjects and display names can arrive as =?charset?B/Q?...?= encoded-words. The declared charset matters just as much as the Base64 or Q encoding around the bytes.
Decoded header text, encoded-word components, charset results and RFC 2047 diagnostics will appear here.
An Encoded-Word Is More Than Base64
RFC 2047 uses the form =?charset?encoding?encoded-text?=. The B form carries Base64 bytes; Q uses a header-specific quoted form. The charset then decides how those bytes become characters.
Decoding only the Base64 portion is therefore incomplete. The same byte can display differently under UTF-8, ISO-8859-1 and Windows-1252, and an unsupported or incorrect charset label can be the reason a subject looks corrupted.
Q Encoding Has Its Own Header Rules
Q looks similar to quoted-printable, but it is not the same thing as a MIME body encoded with quoted-printable. Inside an encoded-word, underscore means an ASCII space and =HH represents one byte in hexadecimal. A literal underscore has to be encoded as=5F.
The allowed literal characters also depend on where the encoded-word appears. A display-name phrase has tighter rules than an unstructured Subject field, which is why conservative Q output escapes punctuation instead of trying to keep every printable character readable.
ISO-8859-1 and Windows-1252 Are Not Interchangeable
They agree across much of the byte range, but Windows-1252 assigns printable characters such as the euro sign and smart quotes to many bytes from 0x80 through 0x9F. ISO-8859-1 treats that range as control characters.
A classic symptom is punctuation turning into controls or replacement characters even though the Base64 itself is valid. Check the declared charset before assuming the transport encoding is broken.
Adjacent Encoded-Words Hide Their Separating Whitespace
=?UTF-8?Q?R=C3=A9sum=C3=A9?= =?UTF-8?Q?_=E2=80=93_API?=
When two encoded-words are next to each other and only linear whitespace sits between them, that whitespace is ignored for display. A visible space must come from the decoded content itself, such as_ or =20 in Q encoding.
This is why plain regex replacement often inserts an extra space or removes one that was intentionally encoded. Header unfolding and encoded-word display rules have to be considered together.
The 75-Character Token Limit and 76-Character Line Limit Are Different
One complete encoded-word cannot exceed 75 characters. RFC 2047 also limits a header line that contains an encoded-word to 76 characters. A field name such as Subject: therefore reduces the room available for the first token.
Long values need several self-contained encoded-words. A UTF-8 multi-byte character cannot be cut between two words, and a Q escape such as =E2 cannot be continued in the next token. Folding with CRLF plus whitespace keeps the logical field value intact.
Do Not Encode an Entire From or To Field as One Word
Address fields have structure. An encoded-word may represent a display-name phrase, but it must not replace the address itself or hide the addr-spec syntax. The same restriction applies to fields such as Received and MIME parameters such asfilename=.
If you are repairing a complete structured header, parse that field first and encode only the text position where RFC 2047 allows it. A decoded display name also says nothing about whether the underlying sender address or authentication results are trustworthy.
Broken Headers Need Tolerant Reading, Not Silent Repair
Old mail archives contain missing Base64 padding, unknown charset labels, malformed Q escapes and strings that merely look like encoded-words. It can be useful to recover readable text, but the damaged source should remain visible.
Missing Base64 padding can be tolerated for inspection while still being reported as non-canonical. Unknown charsets should not be guessed silently. If the decoded result contains control or Unicode bidirectional characters, compare it with the raw header before pasting it into logs or security reports.
Modern SMTP Can Carry UTF-8 Headers Directly
RFC 6532 extends Internet message headers so field bodies can contain Unicode directly when the message is transported with SMTPUTF8. That does not make RFC 2047 disappear: encoded-words remain common in older mail, mixed infrastructure and compatibility-oriented software.
When you control both ends of a modern mail path, check whether direct UTF-8 is already supported before adding legacy encoded-word syntax purely out of habit.
RFC 2047 Sits Inside the Wider Email Format
RFC 2047 defines encoded-word syntax, B/Q rules, legal header contexts, adjacent-word whitespace and length limits. RFC 5322 defines the surrounding Internet message-header syntax and folding.RFC 6532 covers internationalized UTF-8 header fields. For MIME parameters such as filenames, RFC 2231 defines the parameter mechanism instead of RFC 2047 encoded-words.
If the Header Is Only Part of the Problem
A broken subject can be an encoded-word problem, a charset problem, or just one symptom of a larger MIME message issue. Inspect the next layer instead of decoding the same string repeatedly.