The words the inbox adds to your subject line

Ask how long an email subject line should be and you get a confident number, somewhere between thirty and fifty characters, broken out per client and per device. The pages carrying those numbers rarely say where they came from, and none say what they measure, which is one build of one app at one window width with one set of reader settings. A better question hides underneath. What does the reader see on that row before deciding, and which part of it did you write?

The only length rule in the standard

RFC 5322, which defines what an email message is, treats Subject as an unstructured header field with no length rule of its own. The two numbers in the document are about lines, not subjects: a line must be no more than 998 characters and should be no more than 78. The reason given for the softer figure is the whole problem in one clause. It exists for display software that may "truncate, or disastrously wrap" longer lines, and the specification treats losing information that way as working against its intent. The subject you send arrives whole. Everything after that is a layout decision made on someone else's device, under settings you cannot see.

The inbox row is one shared budget

Microsoft documents the row plainly. Its display settings for mail page says Outlook on the web normally shows three lines of information per message: the sender, the subject, and part of the first line of text. The same setting lets the reader hide that preview line, and in the current Outlook they can choose whether the sender name or the subject sits on top, which quietly reverses the hierarchy every subject line guide assumes.

Apple is equally specific. The iPhone guide for checking your email in Mail says Mail shows two lines of body text per message by default and the reader can raise that to five. Litmus, which tests rendering across email clients for a living, puts the practical range at five lines of preview text, around 278 characters, down to none at all, and notes that Gmail lets people switch snippets off. So the row is a shared budget and the split belongs to the reader. One reader sees your subject alone. Another sees a short paragraph of your email before opening anything. A single character count cannot describe both, and since subjects render in a proportional font inside a column that reflows, the cut is set by width rather than by count anyway.

Where the snippet comes from

Gmail does not improvise this at render time. Google's Gmail API reference lists a snippet field on the message resource, documented as a short part of the message text, so the snippet is computed from your body on Google's side and travels with the message. Litmus reports that most clients take it from the first lines of copy, a few fall back to image alt text, and a small number have pulled from markup such as anchor tags.

The snippet is not a marketing feature you opted into. It is the first sentence you already wrote, shown to someone who has not opened the email.

For anyone writing one to one from Gmail, the consequence is blunt. Your first sentence is your preview text, and always was. If it opens with a greeting and a hope that the message finds them well, you have spent the best line on the row on something the reader has already read from everyone else.

What the AI summaries changed

On recent Apple devices the preview is no longer your first line at all. Apple's Mail documentation states that a short summary appears automatically under each email in the inbox, generated from the message itself. Your opening sentence is read by a model and shown back as its paraphrase. No markup opts out and no field steers it.

Take that as clarification. The subject line is the only element that reaches every reader on every device as written, so it has to carry the message by itself. The snippet is upside: write it deliberately, and lose nothing where a client hides it, shrinks it, or rewrites it.

A rule that survives all of this

• Front load the clause, not the character budget. The reader's cut point moves with their window, their font size and their settings. Your first clause does not move.
• Say something new in the first sentence. Repeating the subject spends the snippet for nothing, which Litmus names as a common mistake.
• Write for the reader with no preview line. If the subject alone does not justify an open, more preview text will not rescue it.
• Treat a raw open count as evidence about your list, not a verdict on your phrasing.

Measuring it on your own mail

A benchmark from someone else's list cannot tell you whether your subject worked, because it was never sent to your recipients. Your own sent mail can, if the numbers are clean. Fast Mail Tracker keeps the subject with the send: a saved template holds its own subject field separate from its body, a campaign holds one, and every tracked email keeps the subject it went out with. Comparing two phrasings becomes a question about your own history.

The engagement ramp is sent, seen, opened, clicked, replied, and a confirmed open is held apart from a privacy relay prefetch and from a datacenter scanner. That separation matters here, because a prefetch fires on delivery, before a human has read your subject. Count those as opens and every subject line you write looks about equally good.

One more detail, since this is about what reaches the inbox row. Our tracking pixel is appended at the end of the body, as a one by one image with an empty alt attribute and display set to none, so it can never become your snippet. A tracker that puts an image with alt text near the top of a message can, which is a real way to lose the line you worked on.

The honest ceiling is sample size. A handful of one to one sends gives you a direction, not a result, and no tool can tell you the subject was the reason somebody opened. Fast Mail Tracker is in early access while Google's security review runs, so access is limited for now. To run this comparison on your own threads, start with the install button below this article.