MIME Encoded-Word Decoder
Decode RFC 2047 encoded-words in email subjects and display text, inspect B/Q bytes and charsets, or generate deliberately bounded encoded-words without treating MIME header encoding as generic Base64.
Decoded header text, encoded-word components, charset results and RFC 2047 diagnostics will appear here.
An Encoded-Word Is a Header Token, Not “Base64 Somewhere in an Email”
RFC 2047 encoded-words have a specific shape: =?charset?encoding?encoded-text?=. The charset explains how decoded bytes become characters, and the encoding is either B (Base64) or Q (a header-oriented quoted encoding).
MIME body transfer encodings and header encoded-words solve different problems. A body can use Base64 without any =?charset?B?encoded-text?= wrapper, while a Subject can contain several encoded-words next to ordinary ASCII text.
Q Encoding Is Not the Same as Quoted-Printable Body Encoding
The syntax is related, but RFC 2047 gives Q encoded-words their own rules. Inside an encoded-word, underscore represents an ASCII space, and bytes can be written as =HH hexadecimal escapes.
That means =?UTF-8?Q?Sneha_Yoryantra?= decodes the underscore as a space. Treating the encoded-text as a normal URL or generic quoted-printable string can produce the wrong result.
Whitespace Between Adjacent Encoded-Words Disappears for Display
=?UTF-8?B?U25laGE=?= =?UTF-8?Q?_Yoryantra?=
When encoded-words are adjacent and separated only by linear whitespace, RFC 2047 display decoding ignores that separating whitespace. The decoded characters inside the words decide whether a visible space exists.
This is one reason naive regex replacement often creates an extra space between words or removes a space that was encoded as _ or =20.
75 Characters Is an Encoded-Word Limit, Not Just a Pretty Line-Wrap Preference
RFC 2047 limits each complete encoded-word to 75 characters, including the charset, encoding marker and delimiters. Long Unicode header values therefore need multiple encoded-words.
The encoder splits by Unicode characters and re-encodes each candidate chunk until every generated word fits. Multiple words are folded using CRLF plus whitespace instead of generating one oversized token.
The Charset Is Part of the Data
The same byte value can mean different characters under UTF-8, ISO-8859-1 or Windows-1252. Decoding the Base64 first and then blindly calling the bytes UTF-8 can turn a valid legacy header into replacement characters.
Yoryantra treats ISO-8859-1 and Windows-1252 separately for their 0x80–0x9F behavior, handles US-ASCII range violations, and uses the browser TextDecoder for other recognized charset labels.
Encoded-Words Are Allowed Only in Specific Header Contexts
RFC 2047 does not authorize replacing arbitrary header syntax with encoded-words. They are used in text/phrase contexts such as Subject and display names, with restrictions. Received is not a generic encoded-word field, and MIME parameters such as filename have their own parameter-encoding mechanisms.
This tool decodes recognizable tokens for diagnostics, but it does not pretend to be a complete RFC 5322 address parser or MIME parameter parser.
Broken Mail Often Requires Tolerant Reading and Strict Diagnosis
Real messages contain missing Base64 padding, unknown charset labels, malformed Q escapes and encoded-word-looking strings that do not fully match the grammar. Silently “fixing” all of them makes it hard to know whether the original sender was standards-compliant.
The decoder therefore distinguishes warnings from successful decoding. It can tolerate omitted Base64 padding for inspection while still telling you that the serialized encoded-word is not the canonical form you would generate.
Defines encoded-word syntax, B/Q encodings, contexts, adjacent-word whitespace and the 75-character limit.
Defines the surrounding message-header syntax, including fields and line folding.