What is “Content-Type”?

The Content-Type header tells an email client what kind of data it's looking at and how to display it. Plain text? HTML? An image? A calendar invite? The Content-Type header names it so the client knows what to do with it.

Every part of an email (and yes, most emails have multiple parts) gets its own Content-Type declaration. A newsletter might have one part marked text/plain and another marked text/html. That's how email clients show the HTML version to people who want images and formatting, and the plain text version to people who don't.

Common Content-Type values you'll see:

• text/plain for plain text (no formatting, no images)
• text/html for HTML (what makes newsletters look like newsletters)
• multipart/alternative means "here's the same content in multiple formats, pick your favorite"
• multipart/mixed means "this email has attachments"
• image/jpeg, image/png for embedded images
• application/pdf for PDF attachments
• text/calendar for calendar invites

The structure matters. If you're sending both HTML and plain text versions of the same email (which you should), you wrap them in a multipart/alternative container. If you're attaching files, you use multipart/mixed. Get the structure wrong and some clients will display your HTML as raw code, or show attachments inline when they should be separate files.

Most ESPs handle Content-Type automatically. Mailchimp, Brevo, Postmark, they all build proper multipart messages without you thinking about it. But if you're debugging a rendering issue or building custom SMTP integration, Content-Type is one of the first things to check. Wrong Content-Type? Your perfectly formatted HTML might display as a wall of code tags.

If you're ever troubleshooting why an email looks broken in one client but fine in another, check the raw source. Our Source Analyzer will show you the Content-Type declarations so you can see if the structure matches what the client expects.