Your HTML email has the new date, the right offer and a working button. The plain-text version may still be telling a different story. It is easy to miss when everyone reviewing the campaign sees the designed version.
**A plain-text email contains text and line breaks without HTML styling or embedded images.** It can be a standalone message or an alternative body included alongside HTML in the same email. For a campaign, both versions should give the reader the same essential information and a usable next step.
## Plain-looking HTML is still HTML
A message with a white background, short paragraphs and a blue link may look like an ordinary personal email while still using HTML. Its appearance does not tell you whether a plain-text alternative exists.
In a genuine text body, a URL appears as text. Many mail apps make recognized URLs clickable, but there is no HTML button hiding the destination behind a label. Embedded images, fonts and layout tables belong to the HTML version.
The email format can package multiple versions using `multipart/alternative`. That simply means the message carries alternative representations of the same information, from which the receiving client selects an appropriate format. The format is defined in [RFC 2046](https://www.rfc-editor.org/rfc/rfc2046#section-5.1.4).
Two distinctions matter during review:
- Turning off image loading in an HTML email does not turn it into plain text.
- Copying visible text from the HTML preview does not prove that the sender included a separate text body.
To verify what was sent, inspect the received message's actual content, not just what the editor can display.
## Five differences worth checking before a send
### Dates, prices and offer conditions
Compare the essential facts directly. For an illustrative event reminder, the HTML might have been changed from Thursday to Friday while a manually edited text version still says Thursday. The layouts can differ; the event date cannot.
Check deadlines, time zones, currencies, shipping conditions and eligibility wherever they appear. Read the subject alongside both bodies so a last-minute change has not left three different promises.
### The action and its destination
If the HTML says "Manage your booking," the text version needs a recognizable destination and enough context to explain it. A bare "click here" without a URL gives the reader nowhere to go.
Use the delivered link when checking the destination. Tracking can change the visible URL, and a reachable page may still show the wrong campaign or language. Follow the [campaign link-testing steps](/blog/test-email-campaign-links/) for that part of the review.
### Personalization and fallback values
Read a populated example and one with missing optional data. Raw merge tags, blank greetings and the wrong account name are just as confusing in text as they are in HTML.
If the campaign selects content by region or customer status, verify the corresponding text version for those same cases. The [dynamic-email testing guide](/guides/dynamic-email/) explains how to choose a small useful set of test contacts.
### Reading order
Columns do not translate into a plain-text layout. An automatically generated version can separate a product name from its price or list several links without making clear which item each belongs to.
Read from top to bottom as though the HTML were unavailable. Each item should retain its description and action. Use ordinary paragraphs and line breaks to make the order clear instead of relying on spaces to imitate columns.
### Footer and preference links
Confirm that the intended sender details, unsubscribe path and preference links survive in the text version. Test with a controlled contact so you can verify the expected action without changing a real subscriber's preferences.
Keep the provider's required footer content in place. Do not assume that removing visual formatting removes campaign requirements or makes a marketing message equivalent to a personal reply.
## Mailchimp: review the generated text and tracked links
Mailchimp automatically includes a plain-text version with HTML campaigns and also supports plain-text-only campaigns. Its [plain-text email guide](https://mailchimp.com/help/create-a-plain-text-campaign/) explains the format, tracking and footer behavior.
Review the generated version after finishing the HTML. In a text-only campaign, write the essential message directly rather than trying to reproduce a visual layout with spacing. When click tracking is enabled, Mailchimp can replace URLs with tracking destinations, so inspect the received version too.
For personalized content, an ordinary Mailchimp test send has limits. Contact-specific values need live merge-tag preview or a controlled test segment, as described in the [Mailchimp device-preview guide](/guides/mailchimp-device-rendering/). Resolve the content for the intended test contact before comparing the two bodies.
## HubSpot: manual edits stop automatic text updates
HubSpot automatically creates a plain-text version for marketing emails. Its documentation states that, **after you manually edit that version, it no longer updates to match subsequent changes to the main email**. That makes a final comparison especially useful after a deadline, price or link changes.
In the draft email editor, use **Display options > Plain text version** to review and edit it. HubSpot also documents supported URL formatting and the separate setting for plain-text click tracking. See [Customize plain text emails](https://knowledge.hubspot.com/marketing-email/customize-plain-text-emails) for the current instructions.
Read both versions after the last edit, then send a fresh controlled test. Our [HubSpot preview walkthrough](/guides/hubspot-device-rendering/) covers the delivered-message rendering step for the HTML version.
## Capture and compare the message in MailSlurp
Create a MailSlurp test inbox and send the campaign to it from your normal email platform. For personalization checks, use the appropriate controlled-contact send rather than a preview with all values replaced manually.
Open the received message and compare its content with the final campaign. Keep these checks separate:
1. **Content:** do the text and HTML agree on the facts, recipient-specific values and action?
2. **Message format:** is a separate text part actually included where intended?
3. **Appearance:** does the HTML remain readable in the clients your audience uses?
MailSlurp's [email receiving guide](/guides/receive-emails/) explains message capture. When you need to establish exactly which parts were transmitted, the [email API reference](/docs/api/#getRawEmailContents) provides the raw message including headers and body. An engineer can inspect its `text/plain` and `text/html` parts; text extracted from HTML is not evidence of a separately supplied text part.
Use [device previews](/product/device-previews/) for the appearance check. Render the final delivered HTML message across the relevant desktop and mobile clients, including light and dark modes. A good screenshot of the HTML does not confirm that the text alternative is current.
### Will plain text keep my email out of spam?
Format alone cannot establish inbox placement. Sender history, authentication, recipients and the actual message still matter. Test a proposed text-only campaign through its normal sender using [inbox placement testing](/docs/inbox-placement/), and compare equivalent provider samples before drawing conclusions.
### Can a plain-text email track opens?
An image-based open pixel needs an image load, which a plain-text body does not provide. Click tracking can still use rewritten URLs where the ESP supports it. Read the [email open-rate guide](/blog/email-open-rate/) before comparing reports from different formats.
### Should I use the HTML preview to approve both versions?
Review each body directly. They may be generated or maintained separately, and a correct visual preview can hide stale text. Repeat the comparison after the final campaign change.
[Capture your next campaign in a MailSlurp test inbox](https://app.mailslurp.com/sign-up/?onboardingRequest=testing) and check that every version tells the same story.