What is “Content-Transfer-Encoding”?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

Content-Transfer-Encoding tells email systems how the message body is packaged for transport. SMTP (the protocol that moves email between servers) only understands 7-bit ASCII text. It was built in the 1980s when email was just plain text messages. No attachments, no images, no emojis. If you want to send an image or a PDF or even an emoji, the binary data has to be converted into text first.

That's what Content-Transfer-Encoding handles. It's a header in the email that says "here's how I wrapped this data so SMTP can carry it."

The two most common encodings you'll see:

  • Base64 converts binary data (images, PDFs, videos) into a text-safe format. Every 3 bytes of data becomes 4 characters of text, which means the file grows by about 33% during transit. Once the email arrives, the receiving server decodes it back into the original binary file.
  • Quoted-printable is used for text that's mostly ASCII but has a few special characters (like accented letters or curly quotes). It only encodes the characters that need it, so the overhead is much smaller than base64.

There are also 7bit (plain ASCII, no encoding needed), 8bit (allows non-ASCII characters but some servers reject it), and binary (rarely used, since most servers can't handle it). Your ESP picks the right encoding automatically based on what you're sending.

If you're ever debugging an email that looks garbled or has broken attachments, the Content-Transfer-Encoding header is one place to check. Mismatched encoding (header says base64 but the body isn't actually base64-encoded) will cause the receiving server to choke.

In practice, you don't need to set this yourself. Mailchimp, SendGrid, Postmark, and every other ESP handle it automatically when you upload an attachment or send HTML. But if you're building your own SMTP client or debugging raw email source, understanding Content-Transfer-Encoding helps you read what's happening under the hood.

Want to see it in action? Send yourself an email with an attachment, then view the raw source. You'll see a Content-Transfer-Encoding header for each part of the message (one for the HTML body, one for the attachment, etc.). Check it with our free Source Analyzer if you want to see the full breakdown.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Get personalized encoding help

I read this on the Email Almanac about "What is Content-Transfer-Encoding": "Content-Transfer-Encoding tells email systems how the message body is packaged for transport. SMTP only understands 7-bit ASCII text. If you want to send an image or a PDF or even an emoji, the binary data has to be converted into text first. The two most common encodings: base64 (for attachments, grows files by 33%) and quoted-printable (for text with special characters)." Help me understand how this applies to MY specific situation. I need: 1. Whether I should worry about this or if my ESP handles it 2. How to check if encoding issues are causing delivery problems 3. What to look for in raw email source if attachments break 4. Common encoding mistakes that cause emails to look garbled --- My details (fill in what applies): - Email platform/ESP: e.g. Mailchimp, SendGrid, custom SMTP - What I'm sending: [newsletters with images, transactional emails with PDFs, plain text only] - Current issue: [attachments not opening, garbled text, characters showing as weird symbols] - Experience level: beginner / intermediate / advanced

Edit the yellow boxes, then send to the AI of your choice.