Why might the plain-text and HTML versions differ?¶
title: Why might the plain-text and HTML versions differ? subtitle: They are separate MIME parts that a mail client may render differently, even when they were intended as alternatives. slug: why-might-the-plain-text-and-html-versions-differ series: email-evidence section: content-and-attachments card_type: question_card pathway_order: 28 section_order: 6 status: draft public_safe: true video_ready: true word_count: 601 estimated_read_time_seconds: 249 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - plain text - HTML - multipart alternative - phishing sources: - title: 'RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two' url: https://www.rfc-editor.org/info/rfc2046/ - title: 'RFC 9787: Guidance on End-to-End Email Security' url: https://www.rfc-editor.org/info/rfc9787/ - title: 'RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One' url: https://www.rfc-editor.org/info/rfc2045/ - title: 'Gmail Help: Click-time link protections' url: https://support.google.com/mail/answer/10173182?hl=en
Why might the plain-text and HTML versions differ?¶
They are separate MIME parts that a mail client may render differently, even when they were intended as alternatives.
Script¶
Many emails contain both a plain-text body and an HTML body.
They are separate MIME parts.
The mail client normally chooses which one to display based on its capabilities, settings and security policy.
The two versions are supposed to represent substantially the same message.
They are not guaranteed to be identical.
A legitimate system may generate the plain-text version automatically from the HTML.
Formatting, tables, buttons, images and branding may disappear.
A long web address may be written out in plain text while the HTML shows a short label such as “View account”.
An accessibility or notification system may use slightly different wording.
A customer-management platform may update one template and leave the other unchanged.
Those differences may be harmless.
They may also matter.
A hostile message can place a safe-looking destination in the plain-text version and a different link in the HTML.
It can hide text through colour, size, positioning or styling.
The visible HTML may contain an image of words rather than searchable text.
One version may include instructions or content missing from the other.
A security product may rewrite URLs in one part and not another.
A mail client may display one version while a forensic or search tool indexes the other.
So when the precise content matters, preserve and compare both.
Start with the complete raw message.
Identify whether it contains multipart/alternative.
Locate the text/plain and text/html parts.
Decode them using the stated character sets and transfer encodings.
Keep the originals as well as any readable renderings produced for examination.
Then compare:
the wording;
the sender and organisation names shown in the body;
telephone numbers;
account details;
link destinations;
attachments mentioned;
dates and amounts;
instructions;
and any content visible only through images or styling.
Don’t assume that the last part listed is automatically the one every recipient saw.
The MIME standard gives guidance about preferred alternatives, but actual mail clients, user settings, security products and accessibility tools may make different choices.
Record which application and device the recipient used.
A desktop client may display the HTML version.
A security gateway may create a simplified preview.
A text-only client may show the plain version.
A notification banner may reveal only the first part of one version.
If you need to show what the recipient actually saw, combine the raw structure with screenshots, client settings and witness evidence.
HTML also introduces another distinction.
The displayed words and the underlying action may differ.
A button labelled “Open secure document” may link to an unrelated website.
The plain-text body may expose the full destination, or it may contain a separate URL.
Preserve both rather than copying only the visible wording.
Be aware of security rewriting.
A provider may change URLs to route them through a checking service. An exported original from the provider may differ from the version seen in a third-party client after click protection was applied.
Record which version you acquired and how.
The common mistake is:
“The recipient saw the text, so the raw HTML doesn’t matter.”
The opposite mistake is:
“The HTML and plain text differ, so the email must be malicious.”
Differences are common. The question is whether the difference changes the meaning, destination or action expected from the recipient.
A careful conclusion might say:
“The email contained separate plain-text and HTML versions. The recipient’s client displayed the HTML version. The two versions differed in this wording and these link destinations.”
That explains the evidence without guessing why the difference existed.
Plain text and HTML are alternative presentations of the message.
When the details matter, treat them as separate evidence and compare them.
Key takeaway
Preserve and compare both versions. The difference may be harmless formatting, poor generation or deliberate concealment.
Related questions¶
- What is MIME and why does it matter?
- What should I do with links in a suspicious email?
- What can embedded images reveal?
- What information may disappear if the message is forwarded or exported incorrectly?
Source notes¶
- RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two
- RFC 9787: Guidance on End-to-End Email Security
- RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One
- Gmail Help: Click-time link protections