Introduction
Email was designed for ASCII text. When you send a message with accented characters, emoji, or binary attachments, the mail transfer system needs a way to encode non-ASCII bytes using only printable ASCII characters. Quoted-Printable, defined in RFC 2045, is one of the two standard encodings for email (the other being Base64). It represents non-ASCII bytes as =XX hex sequences while leaving ASCII text mostly untouched. This makes it efficient for text that is mostly ASCII with occasional non-ASCII characters. This tool encodes and decodes Quoted-Printable in your browser.
What this tool does
- Encodes text to Quoted-Printable format per RFC 2045, converting non-ASCII bytes to =XX hex sequences.
- Decodes Quoted-Printable back to UTF-8 text, handling soft line breaks and hex escapes.
- Bidirectional: swap between encode and decode with one click.
- Handles multi-byte UTF-8 sequences correctly, including emoji and CJK characters.
- Wraps encoded lines at 76 characters with soft breaks (= at end of line) as required by the RFC.
How this tool works
The encoder takes the input text, converts it to UTF-8 bytes, then processes each byte. Printable ASCII characters (33-126, excluding =) are left as-is. Spaces and tabs are preserved except at end-of-line, where they are encoded as =20 or =09. All other bytes (including = itself, which is byte 61) are encoded as =XX where XX is the uppercase hexadecimal value. Lines are wrapped at 76 characters with a soft break (= at the end). The decoder reverses this: it removes soft line breaks, then replaces =XX sequences with the corresponding bytes, and decodes the result as UTF-8.
How Quoted-Printable encoding works
Quoted-Printable is defined in Section 6.7 of RFC 2045, which is part of the MIME specification (Multipurpose Internet Mail Extensions). MIME was created by Nathaniel Borenstein and Ned Freed in 1992 (RFC 1341, later revised as RFC 2045-2049) to extend email beyond ASCII.
Encoding rules (RFC 2045, Section 6.7):
1. Any byte (octet) except those in the "safe" range may be represented by =XX where XX is the hexadecimal value. 2. The "safe" range is printable ASCII: 33 through 60, and 62 through 126. The equals sign (61) is excluded because it is the escape character. 3. Space (32) and tab (9) may be left as-is, except at the end of a line, where they must be encoded as =20 and =09 to prevent mail servers from stripping trailing whitespace. 4. Lines must not exceed 76 characters (excluding the trailing CRLF). If a line would exceed this limit, a soft break is inserted: = at the end of the line, followed by CRLF. The decoder removes soft breaks to reconstruct the original content. 5. A hard line break in the original text is represented as CRLF in the encoded output.
Example:
Input: "Cafe resume naive"
Encoded: "Caf=E9 r=E9sum=E9 na=EFve"
Each accented character (e-acute is byte 0xE9, i-circumflex is byte 0xEF) is encoded as =XX. The ASCII characters (C, a, f, space, r, etc.) are left unchanged. This is more efficient than Base64 for text that is mostly ASCII.
Quoted-Printable vs Base64:
| Property | Quoted-Printable | Base64 | |---|---|---| | Encoding overhead | ~10% for mostly ASCII | 33% always | | Readability | Partially human-readable | Not readable | | Best for | Text with mostly ASCII | Binary data | | Standard | RFC 2045 | RFC 2045 |
For text that is almost entirely non-ASCII (e.g., Japanese or Arabic), Quoted-Printable actually produces longer output than Base64 because every byte becomes =XX (3 characters). In those cases, Base64 is preferred. Email clients automatically choose the most efficient encoding based on the content.
How to use this tool
- Paste your text in the input field.
- Select Encode to convert to Quoted-Printable or Decode to convert back.
- The output updates instantly in the output panel.
- Click Swap to reverse the direction and exchange input with output.
- Copy the result for use in email headers, MIME messages, or debugging.
Real-world examples
Encoding an email body with accented characters
A developer tests their email sending code with a message containing French text: "Cafe resume naive". They paste it into the encoder and get "Caf=E9 r=E9sum=E9 na=EFve". They verify that their MIME encoder produces the same output. This confirms their email library correctly implements Quoted-Printable encoding for the Content-Transfer-Encoding header.
Debugging a malformed email
An email administrator receives a support ticket about garbled text in an email. The raw email source contains "Caf=3DE9" instead of "Caf=E9". They paste the encoded text into the decoder and see that the =3D is a literal equals sign (0x3D), meaning the encoding was double-escaped. They identify the bug in the sender's MIME library: it is encoding the = in =E9 as =3D, producing =3DE9 instead of =E9.
Testing with emoji and CJK characters
A QA engineer tests their email system with Unicode content including emoji and Chinese characters. They paste "Hello World" into the encoder. The emoji and CJK characters are multi-byte in UTF-8, so each byte becomes a separate =XX sequence. They verify that the decoder correctly reconstructs the original text from the encoded output, confirming their system handles multi-byte Quoted-Printable correctly.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Quoted-Printable | Low | Email text with mostly ASCII content |
| Base64 | Low | Binary data or non-ASCII-heavy text |
| 8-bit encoding | Low | Modern SMTP with 8BITMIME extension |
Limitations or considerations
Quoted-Printable is designed for email content encoding, not for general-purpose data encoding. It is inefficient for binary data (every byte becomes 3 characters) and for text with high non-ASCII ratios. The encoder wraps lines at 76 characters, which is required by RFC 2045 but may not be necessary for non-email use cases. The decoder handles standard =XX hex escapes and soft line breaks but does not validate that the input is well-formed Quoted-Printable. Malformed input (e.g., =ZZ where ZZ is not valid hex) will produce garbage output rather than an error.
Frequently asked questions
When should I use Quoted-Printable vs Base64?
Use Quoted-Printable for text that is mostly ASCII with a few non-ASCII characters. Use Base64 for binary data or text where most characters are non-ASCII. Quoted-Printable produces shorter output for mostly-ASCII text.
What is a soft line break?
A soft break is an equals sign (=) at the end of a line followed by CRLF. It tells the decoder to join the next line without inserting a line break. This allows encoded lines to stay under the 76-character limit without adding unwanted line breaks in the decoded text.
Why is the equals sign special?
The equals sign (ASCII 61) is the escape character in Quoted-Printable. It prefixes all hex-encoded bytes. A literal equals sign in the input must be encoded as =3D to avoid ambiguity.
Does this handle UTF-8 correctly?
Yes. The encoder converts input text to UTF-8 bytes before encoding. Multi-byte characters (like emoji or CJK) are encoded byte by byte, so a 4-byte emoji becomes four =XX sequences. The decoder reverses this and interprets the result as UTF-8.
Is Quoted-Printable still used?
Yes. Most email clients use it for text bodies with occasional non-ASCII characters. It is defined in RFC 2045 and is one of the two standard Content-Transfer-Encoding values for email text (the other being Base64).
Conclusion
Quoted-Printable is the encoding of choice for email text that is mostly ASCII. Use this tool to encode text for MIME messages or to decode Quoted-Printable content from email sources. For binary-safe encoding, use the Base64 Encode/Decode tool. For URL-safe encoding, use the URL encode/decode function available in your browser's developer tools.