Quoted-Printable Encoder and Decoder

What is quoted-printable?

Quoted-printable is one of the two ways email carries text that will not survive a plain seven-bit channel. It is defined in RFC 2045, the same document that defines base64, and the two are alternatives for exactly the same job. Its trick is to leave alone everything that is already safe and escape only what is not, writing each awkward byte as an equals sign and two hex digits — so an accented letter becomes something like =C3=A9 and everything around it stays readable.

That readability is the whole point. A base64 message is an opaque block; a quoted-printable one is the original text with a scattering of escapes through it, which is why you can usually still read a raw email source and see what it says. If you have ever opened a message and found =E2=80=99 where an apostrophe should be, you have seen quoted-printable that was displayed without being decoded.

This tool goes both ways. It encodes text to quoted-printable and decodes it back, and alongside the result it tells you whether base64 would have been smaller for what you gave it — because for some inputs it would, and the specification leaves that choice to you.

How to use it

1. Pick a direction. Encode turns ordinary text into quoted-printable; Decode takes quoted-printable and gives you the text back. The output updates as you type.
2. Paste your text. Anything goes in — a sentence, a whole message body, or the mangled fragment out of an email you are debugging. Line breaks are handled as the specification requires.
3. Read the comparison. Underneath the output is the size of your text in both encodings and which one wins. When decoding, anything in the input that departs from the encoding rules is listed there too.

Quoted-printable or base64, and where the line falls

The two encodings have completely different cost models, so the answer depends on the text rather than on preference. Quoted-printable spends one character on a byte it can leave alone and three on a byte it cannot, so a text where a fraction p of the bytes need escaping costs 1 + 2p per byte. Base64 spends four characters on every three bytes regardless of what they are, which is 4/3. Set those equal and you get p = 1/6: at about 16.7% non-ASCII bytes the two draw level, and above it base64 wins.

That number ignores line breaks, and counting them moves it — by less than a point, but in a direction that is easy to get backwards. Both encodings have to keep their lines within 76 characters. A quoted-printable soft line break costs three characters, because the equals sign that marks it is itself one of them; a base64 line break costs two. The overheads do not cancel, and carrying both puts the real crossover nearer 15.8%. The arithmetic looks symmetric right up until you count the equals sign.

In practice this splits along the writing system. A message in English, French, Spanish or Portuguese is almost entirely ASCII with a few accents, so quoted-printable comes out at roughly three quarters the size of base64 and stays readable into the bargain. A message in Arabic or Japanese is non-ASCII nearly all the way through, and quoted-printable more than doubles it — those belong in base64, and no amount of preference changes that.

This is worth knowing because a lot of software picks one and never revisits it. If your mail is mostly Latin script, quoted-printable is both smaller and legible. If it is not, you are paying three characters a byte for nothing.

Honest limitations

There is one rule that surprises people and it is the reason =20 shows up at the ends of lines. A space is normally left as itself, but a space or tab that falls at the end of a line has to be encoded. RFC 2045 is unusually candid about why: mail servers are known to pad lines with spaces and others to strip trailing whitespace, so a space left visible at a line end may simply not arrive. Encoding it is the only way to guarantee it survives.

When decoding, this tool reports rather than repairs. The specification closes its definition with a list of things a correct encoder can never produce — lowercase hex digits, an equals sign followed by something that is not hex, an equals sign at the very end, raw bytes above 126, lines past 76 characters — and suggests how a decoder should cope with each. This tool follows those suggestions and then tells you what it found, because if you are decoding a broken message you probably want to know it was broken.

Encoders are also allowed to disagree with each other. The specification says printable characters may be left as themselves, not that they must be, so two correct implementations can produce different output for the same input and both be right. That is why this tool was checked by confirming that its output and a reference implementation's decode to the same bytes in both directions, rather than by demanding the two strings match.

One genuine difference worth flagging: line endings. This tool normalises line breaks to CRLF, which is the form the specification calls canonical for text. Some implementations leave whatever they were given. Both are permitted, and it means a byte-for-byte comparison between two tools can differ on line endings alone without either being wrong.

Why is it free?

Everything happens in your browser. Swapping bytes for escape sequences is not work that needs a server, so there is nothing to run, nothing to bill for and no account to make.

Nothing you paste is uploaded, stored or logged. Email bodies are among the most private things anybody would put in a text box, and the only reliable way to handle that is never to receive them in the first place.