Plain text or HTML? Choose a readable email format

Plain text is a content format, not a synonym for an undecorated email. A text/plain body has no formatting commands. An HTML message can look equally restrained while retaining markup. A multipart/alternative message can carry different representations of the same information for the receiving software to select between.

Microsoft describes plain text as lacking features such as bold text and inline pictures, while HTML supports formatted presentation. It also notes that the receiving program can affect what is displayed. Therefore, review both the appearance and the actual message structure instead of relying on an editor label.

Write down the task before selecting a template. A first message asking whether an outline would be useful usually needs a clear introduction, a concrete offer and a question. It may gain little from a banner, a complex signature or several competing buttons. Start with that complete message and add presentation only when it helps someone understand it.

A requested explanation may need more structure. A reader comparing three implementation stages could benefit from headings and a short list. An annotated diagram might also help, provided the explanation remains available in text. Choose those elements because of the information, rather than copying the appearance of an unrelated newsletter.

Treat the first choice as a working decision. Define what would make you revise it: a broken layout, unclear link, missing information or a specific recipient requirement. If you want to compare commercial outcomes, use a controlled test with the same offer and audience. A prettier preview is not evidence of a better result.

Prepare a master copy containing the real sender identity, relevant context, offer, important conditions and next step. If you maintain separate versions, change the master first and compare each version with it. A shortened text alternative should not silently remove a limitation or turn a request for information into a meeting invitation.

The fictional message below is intentionally complete without a picture or button. A simple HTML version could preserve the same paragraphs and wording. The useful property is that the reader can understand the offer and answer the question without recovering information from decoration.

The example teaches presentation, not audience selection or proven campaign performance. Before adapting it, replace the invented observation with verified context and use the sender information and preferences appropriate to your own campaign.

Use your mail client's original-message or source view when investigating the actual format. The simplified fragment below shows a text version and an HTML version inside one alternative container. It is a teaching fragment, not a complete message to paste into a campaign.

For a content review, concentrate on agreement between the versions. You do not need to build MIME by hand. If the structure is unexpected, record what arrived and ask the person responsible for the sending setup to explain it.

HTML can provide meaningful structure, not just decoration. Microsoft's Outlook guidance recommends descriptive headings and links, useful alternative text for visuals, and readable contrast. It also advises keeping important information out of images alone. Use these features where they help the message rather than treating all formatting as a problem.

Imagine a diagram showing three stages: gather open tasks, assign an owner and confirm the next handover. Add a sentence explaining those stages beside the diagram. Someone should still understand the proposed process if they cannot see it. If a picture adds no information, consider whether it is needed at all.

Read the message in order without relying on colour, position or visual emphasis. Check whether a link label explains its destination and whether the surrounding sentence explains why the reader might visit. The email should offer a clear choice before a click occurs.

An editor preview is one stage in the process. The sending configuration may transform the content. Inspect a test message delivered through the intended workflow, including any signature or preference information inserted after editing. Record which campaign step and settings produced it.

Instantly's text-only delivery documentation describes removing images, converting formatted links to visible URLs and disabling open tracking. It offers campaign-level choices covering all steps or only the first. A workspace setting can enforce a text-only first step across campaigns. These are configuration behaviours to verify, not evidence that a particular setting guarantees better placement.

This matters when the copy says “use the button below” but conversion leaves a text link, or when a long destination disrupts an otherwise concise message. Revise the wording around the actual output. Also check a later step if its format differs from the first; one successful first-message review does not cover the entire sequence.

If a format change affects tracking, update the reporting notes at the same time. A period with no open tracking cannot be compared with a tracked period as though the missing events prove a change in reader interest. The separate tracking guide covers that interpretation in detail.

Choose representative test accounts and devices your team is authorised to use. Send the approved version through the intended route and inspect it as a reader. Note the client and settings rather than reporting a generic “mobile passed” result with no context.

Use the cases below as an acceptance exercise. The question is whether the person can understand the message and take the intended action. It is not an inbox-placement study or a universal compatibility certificate. Expand the cases when a real audience requirement or observed issue gives you a reason.

When a case fails, save the relevant source or screenshot with unnecessary personal information removed, identify the smallest correction and test that correction again. Keep one approved copy reference so the reviewer knows which version is ready.

The useful deliverable is a reasoned choice plus a repeatable check. Keep the record beside the approved campaign copy so a colleague can reproduce the setup without guessing what “plain” meant. Link to the full message rather than copying fragments into several disconnected documents.

Review it when you change the editor, sending tool, signature, tracking, template or information being presented. Reuse the cases that still matter and add any new requirement. For a commercial comparison between formats, define the experiment separately instead of treating this acceptance check as a performance result.