# Email Preview Text Generator and Inbox Source Inspector

> Write intentional inbox preview text, inspect the first text fragments exposed by the final email HTML, model body bleed across narrow and wide stress scenarios, and export the implementation plus a final-build QA record.

- **Canonical page:** [https://emailbump.com/tools/email-preview-text-generator](https://emailbump.com/tools/email-preview-text-generator)
- **Interactive tool:** [Open the email preview text generator](https://emailbump.com/tools/email-preview-text-generator)
- **Category:** email copywriting, HTML implementation, inbox quality assurance, and accessibility
- **Updated:** July 2026
- **Implementation paths:** provider preview-text field, hidden preheader HTML, or deliberate body-first extraction
- **Client stress matrix:** directional Gmail, Apple Mail, Outlook, and Yahoo desktop or mobile scenarios
- **Privacy:** Sender, subject, preview copy, source HTML, findings, and exports remain in the browser
- **Network boundary:** The tool does not request remote images, follow links, load stylesheets, send messages, or connect to a mailbox
- **Parsing boundary:** Source inspection is static and never executes pasted scripts
- **Decision boundary:** The output does not reproduce private mailbox extraction algorithms, guarantee a character count, or prove what a received message will display

## Preview text is an extraction problem

Preview text, sometimes called preheader text or an inbox snippet, is the secondary copy many mailbox interfaces display near the sender and subject.

Writers often treat it as one more field in a campaign brief. The inbox does not receive the brief. It receives the final MIME message after:

- template rendering;
- merge-tag substitution;
- localization;
- conditional content;
- component expansion;
- CSS inlining;
- link tracking and rewriting;
- image-host rewriting;
- minification;
- provider-inserted view-online content;
- footer and compliance injection;
- and any transport-stage changes.

A mailbox then decides whether to display a snippet, how much space is available, and which message content to extract.

The sender can influence the source. The mailbox controls the final interface.

That means good preview-text work has three layers:

1. write a useful second line;
2. place it through a deliberate implementation;
3. inspect and test the final received result.

The existing [email preheader generator](https://emailbump.com/tools/email-preheader-generator.md) helps write subject-aware variants. This tool begins where that writing workshop ends. It focuses on implementation, extraction order, body bleed, fallback content, final HTML, and QA evidence.

## The three implementation paths

### Provider preview-text field

When an email platform offers a documented preview-text or preheader field, prefer it.

The provider can:

- place the value at the expected template position;
- apply its own tested hiding pattern;
- integrate the value with its editor;
- preserve it across compilation;
- and avoid requiring every template author to maintain a custom block.

“Provider field” does not mean “automatically correct.” Inspect the generated HTML and send the compiled message. A platform can change its renderer, duplicate the preview in a template, apply unexpected escaping, or place other content first.

In this mode, the tool exports the intended preview value and includes the source-order scanner for final-build review.

### Hidden preheader HTML

When no supported provider field exists, a hidden block near the start of the HTML body is a common implementation.

The generated block combines:

- display:none;
- mso-hide:all;
- zero maximum dimensions;
- zero opacity;
- hidden overflow;
- hidden visibility;
- one-pixel font and line height;
- transparent text;
- and aria-hidden.

No hiding combination is universal. Email clients use different rendering engines, sanitizers, CSS support, accessibility mappings, and extraction paths. A block that disappears in a browser preview can become visible, occupy space, or be announced differently in an inbox.

Place the block immediately after the opening body tag or at the earliest provider-supported template position. Do not put:

- a browser-view link;
- navigation;
- a logo image with alternative text;
- a tracking notice;
- hidden scaffolding;
- or a template comment expanded into text

before the intentional preview.

The aria-hidden attribute aims to reduce duplicate announcement when the preview repeats information available in the visible body. Assistive-technology and email-client combinations vary. Test the received message, and do not hide information that exists nowhere else.

### Body-first extraction

Some messages intentionally use the opening visible content as the snippet.

This can be robust when:

- the first body sentence is useful on its own;
- there is no utility copy or navigation first;
- the subject and opening do not duplicate each other;
- image alternative text does not intervene;
- and the same opening works across localization and personalization.

Body-first extraction is also the fallback when a dedicated preview is empty, removed, unsupported, or ignored.

The tool joins the earliest exposed non-hidden fragments into a directional source-derived preview. It does not claim that a specific mailbox will join or prioritize the same nodes.

## What the source inspector reads

The page parses pasted HTML with the browser's DOMParser. It does not insert the result into the live page and does not execute scripts.

It walks the document body in source order and records up to twelve early fragments.

### Visible body text

Text nodes inside ordinary elements become visible-body sources. Adjacent fragments with the same element type and visibility can be combined to keep the ledger readable.

The scanner normalizes whitespace. Formatting line breaks and indentation do not create meaningful snippet spaces.

### Linked text

Text inside an anchor is classified separately. Early links often contain:

- “View this email in your browser”;
- navigation;
- account actions;
- preference controls;
- or a primary CTA.

Linked text can be perfectly useful body content and still be a poor inbox opening.

The scanner warns when early text resembles a browser-view link, unsubscribe language, or preference-management language.

### Image alternative text

The scanner records non-empty alt attributes as image-alt sources.

Alternative text is essential for meaningful images when images are unavailable or cannot be perceived. It should describe the image's purpose in context. It is not merely decorative metadata.

Early image alt text can also compete with intentional preview text or become part of a source-derived snippet. A hero image described as “A dashboard showing campaign results” might be acceptable body fallback but a weak second inbox line.

Do not remove useful alt text to manipulate a snippet. Fix source order or add intentional preview text.

An image with an intentionally empty alt attribute is not added to the text-source ledger.

### Hidden text

Elements are treated as hidden in the approximation when they contain common signals such as:

- the hidden attribute;
- aria-hidden=true;
- display:none;
- max-height:0;
- visibility:hidden;
- opacity:0;
- or mso-hide:all.

Mailboxes can extract hidden preview text even though it is not visually rendered in the body. That is one reason source inspection is only an approximation: “hidden for body layout” and “ignored for snippet extraction” are not equivalent concepts.

The ledger makes hidden fragments visible to the operator rather than pretending they do not exist.

### Ignored elements

The scanner skips script, style, head, title, meta, link, and noscript elements.

It does not:

- resolve CSS classes;
- load external stylesheets;
- evaluate media queries;
- calculate browser layout;
- execute conditional comments;
- reproduce Microsoft Office parsing;
- expand template languages;
- render remote content;
- or model a provider's sanitizer.

Paste post-compilation HTML whenever possible.

## The default example

The default compiled HTML intentionally begins with:

“View this email in your browser”

It then exposes:

- hero-image alternative text;
- the headline;
- body copy;
- and a CTA.

The source inspector flags the browser-view link as a risk.

The example also includes intentional preview text:

“Three sends, two audience segments, and the goal for each—ready to review.”

This demonstrates the distinction between good copy and controlled implementation. The preview can be useful while the final HTML still has a risky exposed source order.

A tool that opens with perfect evidence teaches little. The default is designed to show diagnosis, not manufacture a green result.

## Subject and preview should work as a pair

The subject creates the first frame. Preview text should add the next useful fact.

Useful continuations can provide:

- what is inside;
- why it matters;
- a deadline;
- a consequence;
- a status;
- the next step;
- a qualifying detail;
- reassurance;
- or a useful scope boundary.

Weak preview text often:

- repeats the subject;
- repeats the sender name;
- says “Open this email”;
- begins with generic excitement;
- contains unsupported urgency;
- exposes template utility copy;
- or relies on the end of a long sentence.

The tool calculates meaningful-word overlap:

1. lowercase subject and preview;
2. collect letters and numbers into words;
3. remove a small set of common function words;
4. ignore words shorter than three characters;
5. divide shared subject words by meaningful subject words.

An overlap at or above 55% creates a mechanical warning.

This is not semantic analysis. Two lines can use different words and still repeat the same idea. Two lines can share necessary product terms and still work well. Use the result as a prompt for editorial review.

## There is no universal character limit

Preview-text character counts published as universal limits are misleading.

Available snippet space can change with:

- mailbox product;
- desktop, mobile, or notification surface;
- viewport width;
- display density;
- font and zoom;
- account settings;
- sender-name length;
- avatar or logo treatment;
- subject length;
- labels, categories, and timestamps;
- accessibility settings;
- operating system;
- app version;
- localization;
- and product experiments.

Some surfaces omit preview text entirely.

The tool uses seven directional stress profiles:

- Gmail desktop;
- Gmail mobile;
- Apple Mail iPhone;
- Apple Mail macOS;
- Outlook desktop;
- Outlook mobile;
- Yahoo Mail desktop.

Each profile has an approximate subject and snippet grapheme budget. These are deliberately labeled stress budgets, not documented client limits or pixel-perfect screenshots.

Their purpose is to answer:

- Does the first clause work when space is narrow?
- Does a wider view append ugly body content?
- Does the subject lose its differentiating fact?
- Does one implementation rely on the final clause?
- Does body-first mode expose utility copy?

The correct response to variability is front-loading plus real testing, not searching for one magic count.

## Graphemes, words, and truncation

The interface counts JavaScript Unicode code points through Array.from. This is more useful than raw UTF-16 code-unit length for many emoji and non-ASCII characters, but it is not a full Unicode grapheme-cluster segmenter.

A family emoji, flag, combining character sequence, or complex script can occupy one perceived glyph while containing several code points.

Actual visual width also depends on glyph shapes and fonts. Ten wide capital letters consume more space than ten narrow lowercase letters.

The stress matrix truncates by directional code-point budgets and adds an ellipsis. Treat it as copy stress, not visual measurement.

For localized campaigns:

- audit each locale;
- do not assume translated text keeps the same order or length;
- test right-to-left presentation;
- expand merge tags with realistic longest values;
- and verify missing-value behavior.

## Body bleed

Body bleed occurs when a mailbox appends message content after the intended preview text.

For example:

Subject:

Your July campaign plan is ready

Intended preview:

Three sends, two audience segments, and the goal for each.

Possible wider snippet:

Three sends, two audience segments, and the goal for each. View this email in your browser A dashboard showing campaign results...

Body bleed is not always harmful. A well-written first body sentence can make a useful continuation. The safest fallback is meaningful source order.

The simulator models bleed by:

1. taking the selected directional snippet budget;
2. subtracting the intentional preview length;
3. subtracting the modeled buffer reserve for hidden-HTML mode;
4. appending early exposed non-hidden sources when meaningful room remains;
5. truncating the combined string to the stress budget.

Real mailboxes can ignore, collapse, normalize, or extract content differently. The simulated leaked fragment is an inspection prompt.

## Invisible filler

Invisible filler uses entities or characters intended to occupy extraction space without appearing as ordinary visible copy.

The generated optional sequence combines:

- combining grapheme joiner entity 847;
- zero-width non-joiner;
- and a non-breaking space.

The buffer control has five states:

- off;
- 1 through 4.

Each level adds four sequences and reserves a directional amount in the simulator.

Filler is not a standardized preview-text protocol.

Risks include:

- visible blank or unusual characters;
- unexpected wrapping;
- provider escaping;
- client normalization;
- assistive-technology announcement;
- copy-and-paste artifacts;
- source bloat;
- content-filter suspicion;
- and future behavior changes.

Use the smallest tested amount only when appended body text is genuinely harmful.

Do not use filler to compensate for bad source order. Rewrite the body opening so the fallback remains useful.

At levels three or four, the tool creates an explicit warning for a heavy buffer.

## Copy diagnostics

The control score is an editorial and implementation checklist, not a delivery or conversion prediction.

It starts at 100 and applies transparent deductions.

### Missing intentional preview

When provider or hidden mode has no preview text, the tool deducts 35 points. The message falls back toward exposed body sources.

Body-first mode is not penalized merely for leaving the intentional field empty because source extraction is the selected strategy.

### Very short preview

A preview below 28 code points receives a warning and a 12-point deduction. Wider surfaces may append more body content.

This does not mean every preview must be at least 28 characters. A short transactional fact can be excellent. The warning ensures fallback content is reviewed.

### Long preview

A preview over 160 code points receives a note and a small deduction. The end will often be unavailable, so the first clause must carry the value.

### Subject overlap

Meaningful-word overlap of at least 55% deducts 18 points.

### Source-order risk

The first scanner warning deducts 13 points. Fixing one warning can reveal another risk behind it.

### Heavy filler

Filler level three or four deducts six points.

### Empty subject

An empty subject deducts 15 points. Preview text does not replace a truthful, useful subject.

### States

- 88–100: controlled;
- 70–87: review;
- below 70: needs work.

A “controlled” state means no blocking mechanical finding in the model. It does not mean a mailbox test passed.

## A complete QA workflow

### 1. Write the pair

Define:

- sender name;
- subject;
- intended preview;
- audience;
- purpose;
- locale;
- and message state.

Confirm that the subject and preview are truthful and supported by the message.

### 2. Select an implementation

Use the provider field when it exists and is documented for the template path.

Otherwise place hidden preview HTML at the earliest supported point.

Choose body-first only when the opening source is intentionally suitable.

### 3. Compile the final message

Run:

- template rendering;
- reusable modules;
- conditional logic;
- localization;
- realistic personalization;
- CSS inlining;
- link rewriting;
- footer injection;
- and provider compilation.

Copy the final HTML into the inspector.

### 4. Inspect source order

Review the first twelve fragments.

Look for:

- view-online links;
- navigation;
- image alternative text;
- duplicate headings;
- personalization gaps;
- legal copy;
- hidden text;
- and provider-generated content.

Do not remove accessibility content only to improve the inbox snippet. Fix placement and implementation.

### 5. Review stress profiles

Check narrow and wide scenarios.

Confirm:

- the first subject words differentiate the message;
- the first preview clause is useful;
- appended body content is acceptable;
- no missing merge value produces punctuation debris;
- and localization still works.

### 6. Inspect implementation HTML

For hidden mode:

- place the block early;
- escape user-provided characters;
- keep the preview truthful;
- use minimal filler;
- and make sure body content contains equivalent useful information.

The generator escapes ampersands, less-than signs, greater-than signs, and quotes.

### 7. Send representative tests

Send the final compiled MIME message through the production-like route.

Test:

- important mailbox providers;
- desktop and mobile apps;
- light and dark modes;
- images enabled and blocked;
- representative account settings;
- plain-text alternatives;
- and assistive technology where the hidden implementation could duplicate content.

### 8. Archive received evidence

Record:

- template and code revision;
- provider build;
- sender and subject;
- preview implementation;
- locale and personalization case;
- mailbox, app, operating system, and version;
- timestamp;
- screenshot;
- raw received message;
- and observed snippet.

### 9. Monitor changes

Re-test when:

- the provider editor changes;
- shared layout modules move;
- a browser-view link is introduced;
- the hero image changes;
- localization changes;
- dark-mode code changes;
- a client updates;
- or a new content component appears before the message opening.

## Accessibility considerations

Preview text is part of a broader message.

### Avoid hidden-only information

Do not put a critical deadline, price, security warning, or required action only in hidden preview text. The same useful information must appear visibly and accessibly in the message body.

### Prevent duplicate announcement carefully

The generated hidden block uses aria-hidden=true. The intent is to keep assistive technologies from announcing duplicate preview copy before the visible message.

Email accessibility mappings vary. Test the received result with representative screen readers and clients.

### Keep image alt text useful

Alternative text should serve the image's purpose. Do not empty meaningful alt attributes or replace them with filler merely because they appear in the scanner.

### Use meaningful body order

A coherent source order improves:

- body-first fallback;
- screen-reader flow;
- image-blocked reading;
- plain-text transformation;
- and resilience when hiding CSS fails.

### Inspect the plain-text part

The HTML source scanner does not inspect MIME plain text. Ensure the text/plain alternative begins coherently and does not include hidden-HTML entities.

## Export formats

### Client matrix CSV

The CSV contains:

- client;
- surface;
- directional subject budget;
- directional snippet budget;
- subject preview;
- snippet preview;
- leaked body text;
- and state.

Budgets are model inputs, not vendor guarantees.

### JSON QA manifest

The manifest contains:

- generation timestamp;
- method boundary;
- draft inputs;
- analysis score, state, overlap, and findings;
- implementation mode;
- hidden HTML when applicable;
- a flag that filler is non-standard;
- exposed source fragments;
- the complete client stress matrix;
- and required next steps.

### Plain-text QA brief

The brief includes:

- sender;
- subject;
- preview;
- implementation;
- score;
- overlap;
- number of directional bleed scenarios;
- findings;
- and model boundary.

Use it for quick review comments. Preserve the JSON and real received evidence for durable QA.

## What the tool cannot prove

The tool cannot prove:

- that a provider uses its preview field as expected;
- that pasted HTML matches the sent message;
- that CSS classes or external styles hide content;
- that Microsoft conditional markup behaves as intended;
- that one mailbox extracts hidden text;
- that another mailbox ignores filler;
- that the directional budget matches a current interface;
- that a notification surface shows preview text;
- that a client will not generate its own summary;
- that personalization values fit;
- that remote-image behavior is safe;
- that screen readers ignore the hidden block;
- that plain text is coherent;
- that preview copy improves opens;
- or that a received message passed QA.

Only the final received message can provide client-specific evidence.

## Frequently asked questions

### How long should preview text be?

There is no universal safe length. Put the most important new information first, write a complete fragment, and test narrow and wide final inboxes.

### Is preview text the same as a preheader?

The terms are often used interchangeably. Historically, a preheader can also mean visible copy at the top of an email. This tool uses “preview text” for the intended inbox snippet and “hidden preheader HTML” for one implementation.

### Why does Gmail show body text after my preview?

The available snippet area can exceed the intentional copy, and Gmail can append extractable message content. Other clients can do the same. Improve source order and use only a small tested buffer if needed.

### Can I force every client to show exactly my preview?

No. Mailbox products control extraction and display. Sender markup is an influence, not a cross-client command.

### Should I always add filler?

No. Start without it. Add the smallest tested amount only when body bleed creates a real problem and the final body opening cannot solve it alone.

### Why is “View in browser” flagged?

It is useful utility copy but usually a poor inbox second line. Place intentional preview content first or let the provider control the snippet.

### Can image alt text become the preview?

It can appear among early extractable sources. Behavior varies. Keep alt text useful, but do not depend on it as the intentional snippet.

### Does a different subject change preview space?

It can. Layouts allocate space dynamically and differ by surface. The stress model provides separate subject and snippet budgets but does not reproduce a particular client layout engine.

### Can I A/B test preview text?

Yes, when the sender, subject, body, audience allocation, send time, and other material variables are held constant. Define the primary outcome and sample plan before sending. Use the [email A/B test calculator](https://emailbump.com/tools/email-ab-test-calculator.md) for inference planning.

### Does Email Bump store pasted HTML?

No. Parsing and exports occur in the browser.

## Related Email Bump tools and guidance

- [Email preheader generator and copy workshop](https://emailbump.com/tools/email-preheader-generator.md)
- [Subject line and preheader previewer](https://emailbump.com/tools/subject-line-previewer.md)
- [Email accessibility checker](https://emailbump.com/tools/email-accessibility-checker.md)
- [Email word and structure analyzer](https://emailbump.com/tools/email-word-counter.md)
- [Email A/B test calculator](https://emailbump.com/tools/email-ab-test-calculator.md)
- [Email color contrast checker](https://emailbump.com/tools/email-color-contrast-checker.md)
- [Email editor documentation](https://emailbump.com/docs/editor.md)
- [Campaign documentation](https://emailbump.com/docs/campaigns.md)
- [Transactional email documentation](https://emailbump.com/docs/transactional-api.md)
- [Subject-line glossary definition](https://emailbump.com/glossary/subject-line.md)