Decode encoded words from email Subject and From headers, or build your own – the RFC 2047 mechanism that lets ASCII-only headers carry any language.
Show calculation steps
Processed privately in your browser — nothing you paste is uploaded, logged or stored.
Non-ASCII in a mail header
Mail headers are ASCII, so a subject line in another script uses an RFC 2047 encoded-word: =?charset?encoding?text?=, where encoding is B for Base64 or Q for a quoted-printable variant.
Worked example
=?UTF-8?B?Q2Fmw6k=?= → Café =?UTF-8?Q?Caf=C3=A9?= → Café =?ISO-8859-1?Q?Caf=E9?= → Café (different charset, same result)
Where it appears
Subject lines, and display names in From and To. It is why a raw message source shows =?UTF-8?B? in the subject while the client shows ordinary text — and why a subject sometimes arrives as that literal string when a client mishandles it.
B or Q
Q keeps mostly-ASCII text readable in the raw source and is preferred for a subject with a few accented characters. B is more compact when most of the text is non-ASCII, such as a subject entirely in Japanese.
Limits
Encoded-words are limited to 75 characters and must be split across several for longer text; the tool handles the splitting. It does not parse whole messages. Everything runs in your browser.
How to use the MIME Header Encoder and Decoder
- Paste an email header value, such as a Subject line containing encoded words.
- Set the direction. When encoding, choose B for mostly non-ASCII text or Q for mostly ASCII.
- Click "Convert header".
Frequently asked questions
Why do email headers need their own encoding?
Because the original mail standards allowed only 7-bit ASCII in headers. RFC 2047 defines "encoded words" – a wrapper naming a charset and an encoding – so that a Subject line can carry any language while remaining pure ASCII on the wire.
What is the difference between the B and Q encodings?
B is Base64, which suits text that is mostly non-ASCII. Q is a quoted-printable variant that leaves ASCII readable and escapes the rest, which suits mostly-Latin text with a few accents. Both are equally valid.
Why do adjacent encoded words join without a space?
It is a deliberate rule: whitespace between two encoded words is discarded, so that long text can be split across several words – each capped at 75 characters – without introducing spaces that were never in the original.
The charset in a header is not supported. What happens?
The tool falls back to UTF-8 and tells you, because the browser only decodes charsets it knows. The result may be wrong for an unusual legacy charset, and the note makes that explicit rather than hiding it.
