How To Stop Inbox Preview Text Leaking Into Your Email

Inbox preview text, also called preheader text, is the short snippet shown beside or beneath an email’s subject line. It is often taken from the earliest usable text in the message. If you do not supply a deliberate preheader, a mailbox app may display whatever it encounters first: “View in browser”, navigation labels, an image’s alt text, a legal notice, or the opening of the email itself.

That is why teams add a hidden preheader at the very start of the HTML. The trouble begins when that supposedly hidden line becomes visible at the top of the opened message. This is usually a rendering problem, a template conflict, or an overcomplicated hiding technique rather than a deliverability problem.

The aim is not to force every mailbox to show identical preview text. Mailbox providers and email apps ultimately decide whether to show a snippet, how much of it to show and where they obtain it. The practical goal is simpler: put a useful, truthful line early in every relevant version of the message, then make sure it does not disrupt the reading experience when the email is opened.

What “leaking” looks like

A preview-text leak normally falls into one of four patterns:

• The preheader appears above the designed header. A line intended only for the inbox becomes visible, sometimes in tiny text and sometimes as a conspicuous gap.
• The inbox snippet runs into unwanted copy. The intended preheader is too short, so the app continues into “View online”, account details or the first heading.
• Different text appears in different inboxes. The send platform’s preview-text field, the HTML preheader and the plain-text MIME part do not match.
• Whitespace or symbols appear in the message. Padding characters used to fill out the inbox preview are rendered by a client that does not treat them as expected.

These are separate faults. Treating them as one often leads to a pile of CSS declarations that makes the template harder to maintain without fixing the real cause.

Start with the distinction between a preheader and an inbox snippet

A preheader is content you provide. An inbox snippet is the mailbox app’s presentation of message content. Many email service platforms expose a “preview text” field and insert it into the outgoing HTML near the opening <body> tag. If no deliberate text is provided, clients commonly draw from the body instead. Campaign Monitor’s documentation on preview text gives a useful illustration of this behaviour and of platform-inserted hidden preheaders.

That distinction matters because hiding a line in the opened email does not guarantee that every inbox will use it for the snippet; equally, leaving the platform’s preview field blank does not guarantee that no snippet will appear. A recipient can also choose an app or view that does not show preview text at all.

Write the preheader as meaningful copy that can stand on its own. It should complement the subject line rather than repeat it.

Subject line	Better preview text	Weak preview text
Your October statement is ready	See your balance, recent activity and payment date.	Your October statement is ready
Three new autumn recipes	A quick supper, a weekend bake and a make-ahead lunch.	View this email in your browser

Keep the most useful words at the beginning. Available space varies with the app, device, display settings, sender name and subject-line length. There is no universal character count worth designing around.

Choose the right implementation before writing more CSS

Use your platform’s preview-text setting if it produces reliable output

If your email platform supplies a preview-text field, begin there. It can be safer than adding a second custom block because the platform may already add the necessary HTML and spacing. Inspect an actual delivered test, however. Some systems insert the text only at send time, so an editor preview or browser-hosted version may not show the final markup.

Do not also hard-code a preheader unless you know precisely how the platform handles it. Two competing blocks can give recipients duplicated or contradictory inbox copy, while an extra hidden block may be the line that leaks in a particular client.

Use a visible preheader where it suits the design

A small, readable line at the top of the email is the most straightforward option. It works for readers, remains useful when CSS is stripped, and avoids the accessibility ambiguity of hiding duplicate copy. It is especially suitable for newsletters, account messages and editorial emails where the sentence provides orientation after opening.

Make it look intentional: give it normal text size, sufficient contrast and sensible spacing. Do not disguise it with white text on a white background. Colour transformations, dark mode and image blocking can make that approach conspicuous, while the content may still be announced to people using assistive technology.

When a hidden preheader is needed, keep it small and local

For design-led campaigns, a hidden preheader is reasonable. Place a single text-only element immediately after the opening <body> tag, before web-version links, navigation, image fallbacks and the main wrapper. Use inline CSS because email clients do not apply CSS consistently. Gmail documents support for properties including display, max-height and overflow, but its own guidance also makes clear that unsupported CSS may be ignored; other clients have their own rendering behaviour. See Gmail’s CSS support reference.

This is a conservative starting pattern:

<div aria-hidden="true" style="display:none;max-height:0;overflow:hidden;
font-size:1px;line-height:1px;mso-hide:all;">
  Your balance, recent activity and payment date are ready to review.
</div>

The declarations overlap deliberately:

• display:none is the primary instruction to avoid rendering the element.
• max-height:0 and overflow:hidden provide a second constraint where a client handles layout differently.
• font-size:1px and line-height:1px reduce the visual impact if a client honours some declarations but not others.
• mso-hide:all is an Outlook-specific declaration used by many email templates.

aria-hidden="true" is appropriate here only because the preheader repeats information that appears in the subject line or the email’s meaningful opening. It tells supporting assistive technologies to ignore the redundant hidden element. Do not use it on content that someone needs in order to understand or operate the email. The W3C’s WAI-ARIA specification explains that aria-hidden="true" removes an element and its descendants from the accessibility tree.

This code is a compatibility measure, not a command to mailbox providers. Do not rely on an enormous chain of zero-width characters, non-breaking spaces or invisible filler to control every last character in an inbox list. Those techniques can surface as blank space or artefacts, complicate source review and turn an ordinary template change into a rendering fault.

Prevent the preview from continuing into unwanted text

A hidden preheader can itself be correct and still appear followed by unwanted material in the inbox. That happens when the mailbox chooses a longer snippet than the preheader provides. For example:

Intended preheader: “New member prices end Sunday.”
Actual inbox snippet: “New member prices end Sunday. View online | Manage preferences | Unsubscribe…”

The answer is not to add fake wording. First, make the preheader a complete and useful sentence. Then inspect the order of the HTML that follows it. Move utility links below the main content where appropriate, or make the first visible text a sensible continuation if an app reads beyond the preheader.

For example, instead of placing this directly after the preheader:

<a href="...">View this email in your browser</a>

consider whether the message can open with a real heading such as “Member prices on selected winter stays”, with the web-version link positioned elsewhere in the layout. This improves the fallback snippet as well as the opened experience.

It is also worth checking automatically generated copy: web-view links, personalisation defaults, loyalty balances, language selectors, account notices and image alt text. A dynamic field that is blank or unusually long for one recipient can change the apparent first text in the rendered message.

Check the plain-text version as well as the HTML

Marketing emails are commonly sent as multipart/alternative, containing both a plain-text and an HTML representation. The alternatives should express the same message. Current IETF guidance notes that recipients may render different alternatives depending on their capabilities or user preferences, and recommends that parts likely to be viewed as the main body have the same semantic content. See RFC 9787’s guidance on rendering multipart email.

For preview-text control, that means the plain-text version deserves review. If the HTML begins with a carefully written preview line but the text version starts with “View online”, different inboxes or fallback views may expose different snippets. Configure the platform’s plain-text output where it allows this, and make its opening sentence consistent with the intended preheader and email content.

Do not put HTML hiding tricks into the text part. Plain text has no CSS. It should simply be a clean, readable representation of the message, beginning with useful copy.

Why common fixes fail

Using white text

White-on-white preheaders rely on colour rather than actual hiding. They can become visible against a dark or altered background, may take up space, and can be announced as duplicate copy. Use structural hiding or a deliberately visible preheader instead.

Hiding with a CSS class defined in the head

A class such as .preheader { display:none; } can work in some clients, but it is less resilient than inline styling if the client removes or changes the embedded stylesheet. Keep critical preheader declarations on the element itself.

Putting the preheader after a logo or preheader link

Inbox extraction is not a dependable simulation of visual design order. If other text precedes the intended preheader in the source, that other text is a plausible snippet candidate. Put the intended text first.

Adding several hidden blocks

Multiple blocks make it difficult to establish which one is used by the platform or client. They also increase the chance that a partial rendering exposes one of them. Use one source of truth per message version.

Trusting only the email builder preview

Builder previews often do not reproduce the final MIME structure, send-time insertion, personalisation or a real inbox’s snippet selection. A browser “view online” page is useful for layout checks but is not evidence that the delivered message behaves correctly.

Test the delivered message, not just the template

Preview text should be part of ordinary pre-send QA, particularly after a platform migration, template rebuild or ESP change. Test a representative campaign and a representative triggered message separately: their send pipelines may generate different HTML or plain-text parts.

1. Send to controlled test accounts in the mailbox environments most used by your audience.
2. Check the inbox list before opening the message. Capture the subject, sender name and visible snippet.
3. Open the email and look immediately above the header for leaked text, excess height and odd characters.
4. Review the plain-text version and, where available, the original source or rendered MIME parts.
5. Repeat using records with long names, empty optional fields, a different language and other realistic personalisation edge cases.

Email-client rendering changes over time, so tests need to be repeated when a template changes rather than treated as a permanent approval. Specialist inbox-rendering services can make this broader testing more efficient, but a small seed list in real inboxes remains valuable because it exposes the delivered campaign rather than an editor approximation. Litmus’s discussion of Gmail support for display:none is a useful reminder that even long-standing CSS assumptions can change.

When the issue is bigger than a preheader

If a standardised template leaks text only in isolated sends, investigate the actual message construction: send-time content blocks, conditional logic, link tracking rewrites, MIME assembly and platform-level preview settings. If it leaks across a high proportion of messages, treat it as a template and deployment-quality issue before changing campaign copy.

For permission-based programmes, this is also a sensible point to review whether the message is being built and authenticated consistently across sending systems. Email Foundry’s deliverability audits can include infrastructure and message-path checks where a recurring rendering fault sits alongside broader programme issues, but a hidden preheader alone should not be mistaken for a deliverability remedy.

A good implementation is modest: one honest preheader, early in the message source; one clean plain-text equivalent; no fragile filler; and testing in the inboxes that matter to your audience. That gives mailbox apps useful material to display without making the opened email look as though its scaffolding has escaped.

Frequently asked questions

Can you remove inbox preview text entirely?

Not reliably. Whether a snippet appears is controlled by the recipient’s mailbox app and settings. You can provide useful early message text and prevent unwanted utility copy being selected, but you cannot require every client to hide snippets.

Should preheader text be visible in the email body?

It can be. A visible, well-designed preheader is the simplest and most accessible approach. Use a hidden preheader only when the design genuinely calls for it, and make sure the same information is available in the subject line or opening content.

Why does preview text show correctly in Gmail but not Outlook?

Email clients can use different rendering engines, CSS support and snippet-selection behaviour. Check the delivered HTML, the plain-text alternative, the order of the source and any platform-generated blocks rather than assuming one client’s result will apply elsewhere.

Does a hidden preheader affect deliverability?

A normal, relevant hidden preheader is chiefly a presentation technique. It is not a way to improve inbox placement. Avoid excessive hidden filler or misleading copy, and focus deliverability work on permission, authentication, sending practices and recipient engagement.

Sources and further reading

• CSS support for Gmail — Google for Developers
• Preview text documentation — Campaign Monitor
• WAI-ARIA 1.3 — W3C
• RFC 9787: Guidance on End-to-End Email Security — IETF
• Gmail support for display:none in email — Litmus