Email Preheaders: Examples That Work With the Subject Line
Write useful preheaders that complement the subject, protect private information and survive different inbox previews, with practical examples.
TL;DR
- A preheader should add useful context to the subject line rather than repeat it or expose unrelated template text.
- Put the most important information first because inbox previews vary by client, device and user settings.
- MailBlastr supports preview_text for HTML messages, with a maximum of 150 characters; that cap is not a guarantee of visible length.
- Test the actual inbox preview and opened message, including fallback text, personal data and missing variables.
Write the subject and preheader as a pair
The subject introduces the message. The preheader can explain why it matters or what the recipient should do next. When both say exactly the same thing, the second line uses space without adding information.
For example, pair “Your report is ready” with “Review the completed export in your workspace.” The subject identifies the event; the preview supplies the action. Compare that with “Your report is ready—your report is ready,” which adds no useful context.
Do not rely on a universal character count for what recipients will see. Inbox layouts vary, and long subjects can leave less room for preview text. Write a complete short thought with the important information near the beginning, then inspect it in representative clients.
Use state-specific examples
These are original copy examples for a fictional product. Replace them with the actual state and behavior of your application.
| Message | Subject | Preheader |
|---|---|---|
| Completed export | Your export is ready | Download the file from your workspace. |
| Workspace invitation | Morgan invited you to Example | Review the invitation to the Northstar workspace. |
| Saved preferences | Your notification settings changed | Your new preferences are now saved. |
| Incomplete setup | One setup step remains | Choose the destination for your project updates. |
| Payment issue | Please review your payment method | Open billing settings to check the payment issue. |
Each preview reflects an observed event or available action. Avoid promising a completed result when the job is still running. If an export has partial errors, say that in the message and direct the user to the review instead of implying everything succeeded.
Keep private information out of the preview
Inbox previews can appear on a lock screen or shared display. Do not put a password, authentication token, full account number or sensitive document content in a preheader merely to make the message more specific.
A useful preview can identify the task without exposing the confidential detail. “A new document is available in your account” may be more appropriate than including the document's sensitive contents. Choose the wording according to the product and the recipient's expectations.
Personalization deserves the same care. Test missing names and unexpected values. A broken preview such as “Hi undefined” is conspicuous before the user even opens the message, and a long organization name can push the useful action out of view.
Implement one intentional preview
MailBlastr's preview_text field accepts up to 150 characters and injects a hidden element at the beginning of the HTML body. It is excluded from the plain-text part. This is an implementation limit, not a promise that every inbox shows all 150 characters. See the send-email reference.
If your template already includes a preheader component, decide which layer owns the preview. Avoid creating two competing hidden previews or allowing an old template value to appear before the new one.
React Email provides a Preview component for authoring this part of a template. Use it according to the version installed in your project and inspect the rendered output. A development preview of the opened email does not necessarily show how an inbox list will extract its snippet.
Check what follows the preheader
Some inboxes may show additional text after your intended preview. If the next content is “View in browser,” a repeated logo label or a long navigation menu, the snippet can become distracting.
Keep the beginning of the email sensible even when the client extracts more content than expected. A concise first paragraph is useful in both the inbox and the opened message. Avoid fragile formatting tricks whose only purpose is to hide large amounts of filler from one client.
Check the plain-text version independently. Because MailBlastr's injected preview is not part of that version, the plain-text opening should still identify the message and its action without depending on hidden HTML.
Review previews as part of a real send
Send the final template through the same path used in production to controlled accounts. Inspect the inbox list on mobile and desktop, then open the message and confirm that the preview does not appear as an unwanted visible block.
Test a short and long subject, missing optional personalization and a translated or non-ASCII value when your product supports it. Record client and version information for any rendering problem so a future template change can be checked against the same case.
For SaaS welcome messages, the preheader should make the next step clearer. For a subject-line test, keep the preheader fixed if the test is intended to isolate the subject. Treat it as part of the message design, not an afterthought filled in just before sending.