How HTML Email Works And Why It Looks Different

HTML email is formatted mail. It is not a web page. An HTML email is not a web page and usually it is not one message either. Most formatted mail carries the same content twice, once as plain text and once as HTML, with the receiving program choosing which to show you. Almost everything strange about how mail looks comes from that arrangement.

It matters here because a conversion has to pick one of them. A printed or exported copy keeps only what the tool decided to render.

An HTML Email Is the Same Message Written Twice

MIME has a container for exactly this. It is why a simple looking message has structure inside it.

Content-Type: multipart/alternative; boundary="alt-9c2"

--alt-9c2
Content-Type: text/plain; charset=utf-8

  Your order has shipped. Track it at example.net/t/8891

--alt-9c2
Content-Type: text/html; charset=utf-8

  <p>Your order has shipped.
     <a href="...">Track your parcel</a></p>

--alt-9c2--

The word alternative is the instruction. These are versions of one message rather than two parts of it. The client shows whichever it prefers, usually the last one it understands.

The plain part is not a fallback nobody sees. Screen readers use it. So do watch notifications, preview lines, search indexes and spam filters. Send an empty plain part and it still displays correctly for most people, while reading as evasive to a filter. That is a common reason legitimate mail scores badly.

Why HTML Email Looks Different Everywhere

A browser has one job and mail clients have never agreed on theirs.

Outlook on the desktop is the famous case. For years it rendered HTML through the engine from Word rather than a web engine, which handles a much narrower range of layout and styling. Newer versions have moved away from that, so what somebody sees depends on which version they are running rather than on the message.

This is why marketing email is built with tables and inline styles and looks like it was made twenty years ago. That is not neglect. It is the only construction that survives every client, chosen deliberately and repeatedly by people who would rather not.

Where the Images in an HTML Email Actually Are

An image in a message is in one of two places and the difference decides whether it appears offline.

<img src="https://
  example.net/i/9c2.png">

not in the message
requested from a server
  at the moment you look

<img src="cid:logo9c2">

Content-ID: <logo9c2>
  the image travels
  as a part of the
  message itself

A tracking pixel is a linked image doing nothing else. One transparent dot, invisible in the message, existing only to be requested. The request reports that you opened it, roughly when and roughly where from. Blocking remote images is what stops it. That is the whole reason the prompt appears.

What This Means for a Stored HTML Email

Both bodies and both kinds of image are in the file, which has consequences once a message is being kept rather than read.

Linked images stop working when the server does. An archive of newsletters from 2015 is a set of messages full of addresses that answer nothing. The text survived and the pictures were never in the file, which is worth knowing before treating a mail archive as a complete record of what people saw.

Reading What an HTML Email Actually Sent

1. View the source rather than the message. Every client offers it somewhere. The boundaries and the Content-Type lines show you both versions at once.
2. Read the plain part first. It is the version with no styling and no images, which makes it the clearest statement of what the message says.
3. Look for cid references in the HTML. Those images are inside the file. Anything with a full web address is not. It never has been.
4. Notice single pixel images. A one by one image with no visible purpose is a measurement rather than a picture.
5. Compare the two versions where something looks off. A link that reads differently in each is worth a second look. It is one of the oldest tricks in phishing.

That last check is quick and it works. The plain part usually shows the actual address while the HTML shows friendly text over it. Where the two disagree about where a link goes, the plain part is the one that cannot hide anything.

Where a stored message needs reading rather than displaying, seeing both bodies side by side answers more than opening it in a client does. Our EML viewer lays out the parts as parts, including which images travelled with the message and which were only ever addresses.