How email clients render HTML, why plain text still matters, the role of MIME multipart, and practical guidelines for formatting emails that arrive and render correctly.

Email Format Best Practices: HTML, Plain Text, and MIME Structure

Email is older than the web, and its formatting model reflects that age. Unlike a browser that renders a consistent HTML specification, email clients — Gmail, Outlook, Apple Mail, and dozens of others — each implement a subset of HTML and CSS differently. Understanding how email formatting actually works helps you send messages that arrive, render, and read well everywhere.

MIME: the container format

MIME (Multipurpose Internet Mail Extensions) defines how email messages are structured. A simple plain text email has a single body part. An email with both HTML and plain text has a multipart/alternative structure, with the two versions as nested parts.

Content-Type: multipart/alternative; boundary="--boundary"

----boundary
Content-Type: text/plain; charset=utf-8

This is the plain text version.

----boundary
Content-Type: text/html; charset=utf-8

<html><body><p>This is the HTML version.</p></body></html>

The multipart/alternative type tells the client to display the version it prefers — HTML-capable clients render the HTML part, text-only clients show the plain text part.

If the email includes attachments, the structure adds another layer: a multipart/mixed container wraps the content parts and the attachment parts.

HTML email

How HTML rendering in email differs from the web

Modern browsers support a sophisticated CSS specification. Email clients do not.

Outlook on Windows uses Microsoft Word's rendering engine for HTML, which has different CSS support than any browser
Gmail strips <head> and <style> tags in some contexts, requiring inline CSS
Apple Mail and iOS Mail support CSS well but have their own quirks
Dark mode applies automatic color inversion on some clients unless you account for it explicitly

The result is that the same HTML that looks fine in a browser can render very differently in an email client.

What works reliably

Tables for layout: the one thing that works consistently across clients, including Outlook. Modern email templates still use <table> structures for multi-column layouts.
Inline CSS: avoid relying on <style> blocks, because some clients (particularly Gmail in certain rendering modes) strip them. Use style="" attributes on elements.
System fonts or web-safe fonts: custom web fonts loaded via @font-face are not supported everywhere. Fallback to Georgia, Arial, or system UI fonts.
Images with alt text: images are often blocked by default. Alt text is what the user sees before loading images, and it is the fallback if images never load.
Max-width for responsiveness: wrap your content in a <table> or <div> with max-width: 600px and width: 100% for mobile responsiveness.

What to avoid

JavaScript: entirely ignored by email clients (and a deliverability red flag)
CSS float: inconsistent support; use table cells instead
Background images in Outlook: Outlook's Word renderer does not support CSS background images
Fixed pixel widths on containers: breaks on mobile
External stylesheets: usually stripped
position: absolute: not supported reliably

Inline your CSS

Before sending, run your HTML through a CSS inliner that converts:

<style>
  p { color: #333; font-size: 16px; }
</style>
<p>Hello</p>

into:

<p style="color: #333; font-size: 16px;">Hello</p>

Most email service providers and APIs (Rovela included) do this automatically.

Plain text email

Every HTML email should include a plain text alternative.

Why plain text still matters

Some clients prefer text: corporate email gateways, certain mobile mail apps, and assistive technologies may display the plain text part
Spam filters use the text part: many spam filters look at the plain text version. An HTML-only email is suspicious; plain text with no HTML often scores better. The mismatch between HTML and plain text content is also a spam signal.
Readability for certain users: users with visual impairments using screen readers may find well-structured plain text easier to navigate
Debugging: when something goes wrong with an HTML send, the plain text version shows what the content was intended to be

Writing good plain text

Plain text should be the full content of the email, not a stub saying "please view this email in a browser." Format it for readability: use line breaks to separate paragraphs, spell out URLs in full, and use simple ASCII symbols for structure.

Subject: Your order #1042 has shipped

Hi Maria,

Your order has shipped via UPS. Estimated delivery: Tuesday, October 28.

Track your package:
https://www.ups.com/track?tracknum=1Z999AA10123456784

Items in this order:
- Blue Mechanical Keyboard (x1)
- USB-C Cable, 2m (x2)

Questions? Reply to this email or visit rovela.dev/support.

Thanks,
The Rovela Team

Character encoding

Always specify charset=utf-8 in your Content-Type header. UTF-8 encodes all Unicode characters, which matters as soon as your email contains accented characters, emoji, or non-Latin scripts.

Without a charset declaration, some clients default to ASCII or Latin-1, which will corrupt any character outside that range.

Subject lines and preheader text

Subject line

The subject line is the first piece of formatted content a recipient sees. Keep it:

Under 60 characters (anything longer is likely truncated on mobile)
Specific and relevant to the email content
Free of all-caps and excessive punctuation

Preheader text

The preheader is the short text preview that appears after the subject line in the inbox list. If you do not set it explicitly, the client uses the first text it finds in the email body — which is often "View this email in your browser" or your company's logo alt text.

Set it deliberately:

<span style="display:none;max-height:0;overflow:hidden;">
  Your order #1042 has shipped. Estimated delivery Tuesday, October 28.
</span>

The display:none hides it from the rendered email while keeping it visible to the inbox preview.

Sending with the Rovela API

When you send through Rovela, pass both html and text body fields:

{
  "from": "orders@yourstore.com",
  "to": ["customer@example.com"],
  "subject": "Your order has shipped",
  "html": "<p>Your order <strong>#1042</strong> has shipped...</p>",
  "text": "Your order #1042 has shipped..."
}

Rovela constructs the correct MIME structure automatically, inlines CSS in the HTML part, and handles encoding. If you only send html and omit text, Rovela generates a plain text version from the HTML; the explicitly-provided version is better when you want control over how it reads.