RFC 2047 Q-encoding is how non-ASCII text — accented names, emoji, other scripts — is safely placed in email headers such as Subject and From. It wraps the text in an encoded-word: =?UTF-8?Q?...?=. This tool encodes and decodes Q encoded-words in your browser.
How it works
The encoded-word format is =?charset?encoding?encoded-text?=. For the Q encoding:
- The text is first converted to UTF-8 bytes with
TextEncoder. - Printable ASCII bytes pass through unchanged, except that space becomes
_, and=,?, and_are always escaped because they are structural. - Every other byte (any byte over 0x7E, control characters, and the escaped ones) becomes
=followed by two uppercase hex digits — for exampleé(UTF-80xC3 0xA9) becomes=C3=A9. - The result is wrapped as
=?UTF-8?Q?...?=.
Decoding reverses this: it reads the charset and Q marker, turns _ back into a space, and converts each =XX back into its byte before UTF-8 decoding.
Tips and examples
The subject Café encodes to =?UTF-8?Q?Caf=C3=A9?=. A space-separated phrase like Re: déjà vu becomes =?UTF-8?Q?Re=3A_d=C3=A9j=C3=A0_vu?= — note the ?-equivalent colon escaping and the underscore for the space. Keep each encoded-word under 75 characters; the tool warns you when a value is long enough that a real mail client would need to split it across multiple encoded-words.
When you encounter Q-encoding in practice
Raw email source — if you open the raw source of an email with a non-ASCII subject or sender name, you will see =?UTF-8?Q?...?= strings. Pasting them into the decode tab here converts them back to readable text immediately, which is useful when debugging deliverability issues or inspecting headers.
Email APIs and SMTP libraries — most modern email libraries (Python’s email.header, Node’s nodemailer, etc.) handle encoding automatically for you. Q-encoding is most relevant when you are building at a lower level, crafting raw MIME messages, or writing a custom mail processing tool.
Display name encoding — the From: and To: headers support a display name before the angle-bracketed address. A sender like José García at [email protected] requires the name portion to be Q-encoded when it contains non-ASCII characters. The resulting header looks like: =?UTF-8?Q?Jos=C3=A9_Garc=C3=ADa?= <[email protected]>.
Q-encoding versus B-encoding
RFC 2047 offers two variants for encoded-words: Q and B (Base64). The rule of thumb:
- Q-encoding is efficient when the text is mostly ASCII with a few non-ASCII characters. The ASCII parts stay literal and readable in the raw source, which aids debugging.
- B-encoding is more compact when the majority of characters are non-ASCII — for example, a Japanese or Arabic subject. B-encoding always produces a fixed 33% expansion regardless of input, while Q-encoding triples the size of each non-ASCII byte.
Most European-language subjects benefit from Q-encoding; Asian-script subjects benefit from B-encoding.
Q-encoding versus Quoted-Printable body encoding
It is easy to confuse RFC 2047 Q-encoding with RFC 2045 Quoted-Printable, because both use =XX syntax. They serve different purposes:
- RFC 2047 Q-encoding applies to header fields only (Subject, From display name). Each encoded-word is wrapped in
=?charset?Q?...?=delimiters and has a strict 75-character limit per word. - RFC 2045 Quoted-Printable applies to message bodies. It encodes bytes similarly but has different escaping rules — a space is
=20(not_), and soft line breaks at 76 characters are added with a trailing=.
Pasting a Quoted-Printable email body into this tool (which is for header Q-encoding) will decode it incorrectly because of the underscore/space difference. Use the dedicated Quoted-Printable tool for body encoding.