What is an email preheader?

The preheader — also called preview text — is the short snippet an inbox shows next to or beneath the subject line before you open the email. It is pulled from a preview-text field or, if none is set, from the first readable text in the email body. It is prime inbox real estate that helps decide whether someone opens, and most sends either leave it empty or waste it repeating the subject.

How long should a preheader be?

Front-load the essential message into the first 40 characters so it survives every client, including the ones that cut earliest, then extend toward about 90 characters to fill the more generous previews like Apple Mail. There is no single perfect number because clients differ — the smallest cut around 40 and the largest show 100+ — which is why front-loading beats aiming for one length.

What happens if I don't set preview text?

The client doesn't show a blank line — it pulls the first readable text from the top of your HTML and shows that instead. On most templates that is the “View in browser” link, a legal line, or your logo's alt text. So the line under your subject reads as body junk. Setting a preheader, or using the hidden-preheader spacer technique, prevents it.

Why does my preheader show body text after it?

Because it is shorter than the client's preview area, so the client pads the remaining space with the first body content it finds. Even a preheader that fits can trail off into body text on a roomy client like Apple Mail. The fix is either a longer preheader or the hidden-preheader technique, which uses zero-width and non-breaking-space entities to fill the preview so nothing leaks in.

What is the hidden-preheader technique?

A hidden div at the top of the email body — styled display:none, max-height:0, overflow:hidden and mso-hide:all — that holds your preview text, followed by a run of zero-width-non-joiner and non-breaking-space spacer characters. The spacers render invisibly but occupy the preview area, pushing any body content (like a “View in browser” line) out of the inbox preview. It is the standard way to control preview text precisely.

Are these character limits exact?

No — they are indicative. Preview truncation depends on the client, the device, the screen orientation, the font size and the window width, so any fixed number is an approximation. The figures here are compiled from commonly published client measurements to show the shape of the problem, which is consistent even when the exact cut moves: front-load the message and it survives regardless.

Should the preheader repeat the subject line?

No. The inbox shows both lines together, so a preheader that restates the subject spends the second line saying nothing new. Use the subject as the hook and the preheader to extend it — the offer, the deadline, the specific reason this email is worth opening. A repeated subject reads as a filled-but-empty field.

Does this preheader tool send my copy anywhere?

No. Everything runs in the browser — the preview rendering, the length checks and the warnings. There is no request, no account and no storage beyond the tab you have open. Close the tab and nothing is kept.

← All apps

Preheader Optimiser

Name: Orbit MCP
Availability: InStock

See the inbox preview the way six clients actually render it, before you send. Runs entirely in your browser.

Your email

Subject line

Preheader (preview text)

0 characters · 0 words

Front-load the message. The smallest previews cut around 40 characters and the most generous show 90+, so no single length fits all. Put the reason to open in the first 40 characters and it survives every client.

Inbox preview

Truncation points are indicative

Type a subject and preheader to see how each client renders the inbox preview — including where the words get cut and where body content fills the rest.

Client budgets are indicative, compiled from commonly published measurements and shown to illustrate the shape of the problem. Exact cuts vary by device, orientation and font size.

Why the preheader matters

An empty preheader isn’t blank — the client fills it with the first body text it finds, usually “View in browser”. A preheader is free real estate next to your subject, and it decides opens. Lifecycle email guides cover the full pre-send checklist, including preview text and the hidden-preheader technique.

Preheader

Add preview text to preview and check it.

0 characters · front-load by 40, fill toward 90

This session

Saved drafts appear here. Click any to reload it. Kept in this tab only — nothing is stored or sent anywhere.

How to write a preheader that earns the second line of the inbox

The preheader is the most under-worked line in email. It is free real estate the inbox hands you next to the subject, and most sends either leave it empty — so the client fills it with “View in browser” — or waste it repeating the subject word for word. Both are visible in every inbox and both are a five-minute fix.

An empty preheader is not blank — it's whatever comes first

When you don't set preview text, the client doesn't show nothing. It reaches into the top of your HTML and pulls the first readable text it finds, then shows that next to the subject. On most templates the first readable text is the “View this email in your browser” line, a legal disclaimer, or the alt text of your logo. So the second line of the inbox — the line right under your subject, the one that helps decide the open — reads “View in browser”.

This is the single most common preheader mistake and the easiest to catch, because it is visible in your own inbox the moment you send yourself a test. The builder above shows exactly what leaks in when the preheader is empty or short, per client.

Too short, and the client pads it anyway

Setting a preheader doesn't stop the leak on its own. If the preview text is shorter than the space the client has, the client fills the rest with body content — the same “View in browser” junk, just pushed a few words to the right. The roomier the client's preview, the more it pads: Apple Mail on an iPhone shows around two lines, so a short preheader there trails off into whatever your body starts with.

There is a real tension here that no single character count resolves. The smallest previews cut around forty characters; the most generous show ninety or more. No length both fills Apple Mail and survives Outlook mobile intact. The answer is to front-load: put the reason to open in the first forty characters so it survives every client, then extend toward ninety to fill the generous ones. The tool marks both thresholds.

Too long, and the payload never shows

Past about ninety characters, only Gmail on desktop keeps reading. The mobile clients — where most opens happen — cut far earlier, some before forty. Anything you put at the end of a long preheader is written for an audience of almost nobody.

Treat the preheader like the subject: one clear idea, front-loaded. The offer, the deadline, the reason this send is different from the last. If it doesn't fit in the first line a phone shows, it isn't doing the job the preheader exists to do.

Repeating the subject wastes the line

The inbox shows the subject and the preheader together, as two lines. When the preheader restates the subject, the reader gets the same message twice and learns nothing new from the second line. It is the copy equivalent of a blank field — technically filled, functionally empty.

The preheader's job is to extend the subject, not echo it. If the subject is the hook, the preheader is the reason to bite: the detail that turns curiosity into a click. The builder flags an exact match, a near-restatement, and a high word overlap, because all three read as a repeat in the inbox.

The hidden-preheader technique, for when the body leaks

The durable fix for body-content leakage is the hidden preheader: a div at the very top of your email body, hidden from view with inline styles, holding your preview text — followed by a run of spacer entities that fill the rest of the preview so nothing after it can leak in.

The pattern is a hidden container styled `display:none;max-height:0;overflow:hidden;mso-hide:all`, then your preview copy, then a sequence of zero-width-non-joiner and non-breaking-space pairs. These characters render as nothing but occupy the preview, pushing “View in browser” out of sight. Every serious ESP template ships some version of this; if yours doesn't, this is the block to add.

Frequently asked questions

What is an email preheader?: The preheader — also called preview text — is the short snippet an inbox shows next to or beneath the subject line before you open the email. It is pulled from a preview-text field or, if none is set, from the first readable text in the email body. It is prime inbox real estate that helps decide whether someone opens, and most sends either leave it empty or waste it repeating the subject.
How long should a preheader be?: Front-load the essential message into the first 40 characters so it survives every client, including the ones that cut earliest, then extend toward about 90 characters to fill the more generous previews like Apple Mail. There is no single perfect number because clients differ — the smallest cut around 40 and the largest show 100+ — which is why front-loading beats aiming for one length.
What happens if I don't set preview text?: The client doesn't show a blank line — it pulls the first readable text from the top of your HTML and shows that instead. On most templates that is the “View in browser” link, a legal line, or your logo's alt text. So the line under your subject reads as body junk. Setting a preheader, or using the hidden-preheader spacer technique, prevents it.
Why does my preheader show body text after it?: Because it is shorter than the client's preview area, so the client pads the remaining space with the first body content it finds. Even a preheader that fits can trail off into body text on a roomy client like Apple Mail. The fix is either a longer preheader or the hidden-preheader technique, which uses zero-width and non-breaking-space entities to fill the preview so nothing leaks in.
What is the hidden-preheader technique?: A hidden div at the top of the email body — styled display:none, max-height:0, overflow:hidden and mso-hide:all — that holds your preview text, followed by a run of zero-width-non-joiner and non-breaking-space spacer characters. The spacers render invisibly but occupy the preview area, pushing any body content (like a “View in browser” line) out of the inbox preview. It is the standard way to control preview text precisely.
Are these character limits exact?: No — they are indicative. Preview truncation depends on the client, the device, the screen orientation, the font size and the window width, so any fixed number is an approximation. The figures here are compiled from commonly published client measurements to show the shape of the problem, which is consistent even when the exact cut moves: front-load the message and it survives regardless.
Should the preheader repeat the subject line?: No. The inbox shows both lines together, so a preheader that restates the subject spends the second line saying nothing new. Use the subject as the hook and the preheader to extend it — the offer, the deadline, the specific reason this email is worth opening. A repeated subject reads as a filled-but-empty field.
Does this preheader tool send my copy anywhere?: No. Everything runs in the browser — the preview rendering, the length checks and the warnings. There is no request, no account and no storage beyond the tab you have open. Close the tab and nothing is kept.

Built into Orbit

Copy and render QA in Orbit

Orbit's copy-readiness and render tools check subject and preheader length, preview leakage and dark-mode rendering as part of the pre-send gate, so the preheader is caught before the send rather than in your own inbox after it. Claude can run the check across a whole programme and list the sends missing preview text.

Orbit web apps