Quoted-Printable Quoted-Printable Encoding Encoding Schemes
A MIME-era binary-to-text scheme optimized for mostly-ASCII content with occasional special characters — still common in email, less so elsewhere.
What it is
Quoted-Printable is a MIME content-transfer-encoding scheme designed for text that's mostly printable ASCII with occasional special characters — the opposite optimization target from Base64, which transforms an entire payload uniformly regardless of content. Quoted-Printable leaves ordinary readable text alone and only escapes the specific bytes that need it (non-ASCII characters, certain control characters, and the = character itself), using an =XX hexadecimal escape format.
It remains common in email today (as one of the standard MIME content-transfer-encoding options alongside Base64 and 7-bit/8-bit), precisely because most email body text is mostly-ASCII with occasional accented characters or symbols — a good fit for Quoted-Printable's design goal of keeping encoded output largely human-readable.
Byte structure
| Content | Encoding |
|---|---|
| Most printable ASCII | Passed through unmodified |
| Non-ASCII bytes | Escaped as =XX (two hex digits representing the byte value) |
Literal = character |
Escaped as =3D, since = is the scheme's own escape marker |
| Line-length management | Lines exceeding 76 characters get a soft line break (= followed by a line ending) that decoders reassemble transparently |
Why your text is garbled (symptom → cause)
| Symptom | Likely cause |
|---|---|
Email body shows literal =XX sequences or = followed by a line break |
Content is Quoted-Printable-encoded but being displayed/parsed as raw text rather than decoded — usually an email client or parsing tool failing to recognize the Content-Transfer-Encoding: quoted-printable header |
Accented characters in an email show as =C3=A9 instead of the intended letter |
Correct Quoted-Printable escaping of a UTF-8 byte sequence — expected behavior when properly decoded, a display bug when it shows up raw |
| Unexpected line breaks appear mid-sentence in email content | Quoted-Printable's soft line-break mechanism (= at end of line) not being reassembled correctly by a non-compliant parser |
Compatibility & gotchas
- Optimized for mostly-ASCII content, unlike Base64 which is uniform regardless of content — Quoted-Printable produces much more compact, more human-readable output for typical email text, but is less efficient than Base64 for content that's heavily non-ASCII or genuinely binary.
- The
=XXescape and=line-continuation mechanisms can both cause visible artifacts if a system fails to properly decode Quoted-Printable content — recognizable by their distinctive=prefix pattern, unlike most other mojibake symptoms. - Still actively used in email (MIME) infrastructure as of 2026, unlike some of the other historical schemes on this list (UTF-7 especially) that have become largely obsolete — Quoted-Printable remains a practical, current choice specifically for email content-transfer-encoding.
Fixing it
- Decoding Quoted-Printable content: most email libraries handle this automatically when they correctly recognize the
Content-Transfer-Encoding: quoted-printableMIME header — if you're seeing raw=XXsequences, check that this header is present and being respected by whatever tool is processing the message. - Manual decoding: Python's
quoprimodule (quopri.decodestring()) handles Quoted-Printable decoding directly if you need to process it outside a full email-parsing library.
Comparison
| Scheme | Key difference from Quoted-Printable |
|---|---|
| Base64 | Encodes the entire payload uniformly regardless of content — better for genuinely binary or heavily non-ASCII data, worse for mostly-ASCII text where it needlessly inflates size |
| UTF-7 | Also a 7-bit-safe scheme with some conceptual overlap, but structured very differently (Base64-style runs wrapped in +...- markers rather than per-byte =XX escapes) |
FAQ
Why do I sometimes see =XX or a trailing = in raw email content?
This is unescaped Quoted-Printable encoding showing through — the email content is encoded per MIME's Content-Transfer-Encoding: quoted-printable scheme, but whatever is displaying it isn't decoding it properly. A correctly configured email client handles this transparently.
Is Quoted-Printable still used, or is it obsolete like UTF-7?
Still actively used — it remains one of the standard MIME content-transfer-encoding options for email and is a genuinely reasonable choice for mostly-ASCII email content, unlike UTF-7 which has fallen out of practical use.
Should I use Quoted-Printable or Base64 for my use case?
Quoted-Printable is more efficient and more human-readable for content that's mostly ASCII with occasional special characters (typical prose email content). Base64 is more appropriate for genuinely binary data or content with a high proportion of non-ASCII bytes, where Quoted-Printable's per-byte escaping would bloat the output more than Base64's uniform transformation.
Fun fact
Quoted-Printable's 76-character soft line-break limit traces back to old SMTP line-length restrictions from an era when some mail transport systems couldn't reliably handle very long lines — a constraint from 1980s-era email infrastructure that's still baked into the modern MIME specification, even though virtually no current mail server actually enforces that original line-length limitation.