Quoted-Printable Encoder / Decoder

Encode and decode email-safe Quoted-Printable (QP) encoded text per RFC 2045.

Tested tool guide Tested browser tools Checked August 16, 2026

What Quoted-Printable Encoder / Decoder does, with a checked example

Quoted-Printable is the MIME encoding that keeps email text mostly human-readable: printable ASCII characters survive as themselves, while everything else becomes an equals sign followed by two uppercase hex digits. This tool applies RFC 2045's rules in both directions, so raw message source or hand-made text pasted in is converted in place. The usual surprises: the equals sign is the one printable character that must be encoded, so every = you type comes back as =3D, and accented characters become UTF-8 byte pairs such as =C3=A9. Everything is computed locally in the browser; pasted email never leaves your machine.

Worked example

A concrete input and expected output from the current implementation.

Input

Café = 100%

Expected output

Caf=C3=A9 =3D 100%

C, a, and f are printable ASCII and pass through unchanged. é is the UTF-8 bytes C3 A9, so it becomes =C3=A9. The equals sign is always encoded as =3D, and the digits and percent sign are printable, so they stay literal.

How the result is produced

One rule for every byte

Each octet is either kept or escaped. Bytes 33-126, the printable ASCII range, are written as themselves, with one exception: the equals sign (byte 61) must become =3D. Everything else, including control characters, DEL, and bytes 128-255, is written as =XX in uppercase hex. Because the input is UTF-8 text, an accented character usually occupies two or three bytes and produces that many escape sequences; decoding inverts the rule.

Lines and the 76-character limit

Encoded lines may not exceed 76 characters. A line that would run longer is split with a soft break: a literal = as the last character, followed by a line break, which the decoder discards. Source line breaks stay as CRLF line breaks, not =0D=0A, and a space or tab at the end of a line is always encoded as =20 or =09 because mail transports strip trailing whitespace.

Good uses

You open raw email source (a .eml file, or 'show original' in a mail client) and the body is full of =C3=A9 sequences; decode it to read what the sender actually wrote.
You need to move text with accents, emoji, or control characters through a 7-bit channel, a legacy system, or a log pipeline that corrupts high bytes; encoding it first guarantees the bytes arrive intact.
You want to verify that a mail library or gateway encoded a message correctly: decode its quoted-printable output, compare the result with the original text, and check that no encoded line exceeds 76 characters.

Limits and checks

The =XX pairs are raw bytes, not characters: =C3=A9 reads as é in UTF-8 but as Ã© in Latin-1. Match the charset the message declares in its Content-Type header, or the decoded text is mojibake even though the encoding itself is flawless.
Subject-line encoding such as =?UTF-8?Q?...?= is RFC 2047 Q-encoding, a different scheme where underscore means space and the =? and ?= delimiters are not Quoted-Printable. Pasting an encoded-word into this tool does not reveal the subject text; decode the header with an RFC 2047 decoder instead.
Soft breaks are fragile: the = ending a line must remain that line's final character. Pasting encoded output into a field that trims, wraps, or reflows lines breaks the encoding silently, and decoding later yields garbage. Compare decoded text rather than encoded strings, since a space may legally be written either literally or as =20.

Common questions

I decoded a message and got Ã© where an é should be. What happened?

The sender's bytes were probably written under one charset and decoded under another. Quoted-Printable preserves bytes, not characters, and the same =XX pairs render differently per charset: =C3=A9 is é in UTF-8 but Ã© in Latin-1. Check the charset in the message's Content-Type header, then decode again with that charset selected.

Why do lines in my encoded output end with a lone =?

That is a soft line break, inserted to keep every encoded line at or under the 76-character limit. It is not part of your data: when the output is decoded, the = and the line break after it are discarded and the text is rejoined. Copy the encoded text verbatim; anything that edits or removes those trailing = signs corrupts the message.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.