Cold email subject-line character count in

Write the shortest honest subject that lets the recipient understand the point of the message. Put the identifying detail and reason for contact early, then inspect real test messages in the clients your buyers use. A desktop preview, narrow phone view and assistive reading workflow can expose different problems. A character counter alone cannot tell you whether the important word appears before truncation or whether the phrase makes sense when read aloud.

1. What the email standard actually limits

RFC 5322 defines Subject as an unstructured informational header field that can contain text or folded white space✓ . The RFC says these informational fields are intended to be human-readable✓ . That is a useful design principle: make the subject a compact, truthful summary of the message, not a puzzle whose missing context appears only in the body. 1

The same RFC says each line must be no longer than 998 characters and should be no longer than 78, excluding the line ending✓ . The conservative recommendation addresses display implementations that may truncate or wrap more than 78 characters per line✓ . It does not say that 78 visible subject characters will display completely on every phone, nor that a subject near that length performs better than a shorter one. Do not use the RFC line value as an industry conversion benchmark. 1

There is also a difference between the human-visible text and the wire representation of a header. Long headers may be folded, and internationalized text may require encoding. Counting Unicode characters in a spreadsheet is not the same as checking how the final message is transmitted or presented. A test must inspect the actual sent message, not just a draft field.

2. Characters, bytes and internationalized subjects

RFC 6532 expands email headers so Unicode can appear in most header content✓ . It also distinguishes the body of a header from the field name: the body may contain Unicode, but header field names remain ASCII✓ . The specification notes that this format needs SMTPUTF8 when carried over SMTP✓ . 2

UTF-8 may use several octets for one character, so a subject with accents, non-Latin scripts or symbols can consume more wire bytes than a naive visible-character count suggests✓ . Avoid deriving a universal display rule from an English-only character limit. If you send localized messages, test each language in the actual infrastructure and client mix. Preserve names and meaning rather than stripping characters merely to reach an arbitrary count. 2

Older encoding mechanisms introduce another number that is often misread. RFC 2047 limits an individual encoded-word to 75 characters, including encoding syntax, and permits multiple encoded-words when more text is needed✓ . That 75-character unit is not the allowable length of the whole visible subject and should never be presented as the recommended copy length. 3

Microsoft documentation adds product-specific constraints, again distinct from an ideal display length. Its MAPI guidance calls the subject an optional property that summarizes message intent, and says a 128-byte compatibility concern comes from some message-store providers rather than MAPI itself✓ . Exchange Online separately documents a 255-character subject length limit✓ . These limits serve different software contexts. None is a promise that all text remains visible in a particular inbox row. 45

3. Put meaning ahead of the cutoff

Because display space varies, write a subject that remains intelligible if its trailing words are hidden. Start with the buyer's actual context or the specific topic, not with a long preamble. For example, a message about a procurement workflow should identify that workflow before adding a qualifier. If the only distinguishing detail sits at the end, the displayed fragment may look generic.

The subject should still match the body. The FTC's commercial-email guidance says not to use deceptive subject lines and says the subject must accurately reflect message content✓ . That applies regardless of whether the subject is ten characters or seventy. Do not imply an existing relationship, a confirmed meeting or an urgent account problem unless the message genuinely supports it. 6

Avoid optimizing for truncation by removing essential qualifiers. A subject that says 'security issue' when the email is really a sales pitch is misleading. The goal is a concise, accurate preview of the reason to read. Microsoft likewise describes the subject property as summarizing the intent of the message✓ . If you cannot summarize the intent plainly, revise the message before debating two extra words in the header. 4

4. Test the rendered message, not a number in isolation

Create a small client-display test matrix. Send the actual message from the production platform to representative Gmail, Outlook and mobile accounts that you control. Check the inbox list, conversation view, any preview text shown next to the subject and the full message header. Do this at a narrow and a wide display width. Note which words remain visible and whether the subject still makes sense without the end. RFC 5322's display rationale is exactly why real rendering matters✓ . 1

For accessibility, read the subject as a stand-alone sentence or phrase. If the recipient relies on assistive technology, a vague teaser forces them to enter the message just to learn its purpose. Place the topic before decorative punctuation. Avoid symbol sequences that are hard to pronounce or that carry the meaning only visually. These are practical editorial checks, not a claim that one character count solves accessibility.

Count the final visible text and, where relevant, the resulting encoded header. Store the count with the exact copy version and language. If you use personalization tokens, test a short and long replacement value so the longest plausible company or name does not push the key phrase out of view. A test using the literal token placeholder is not representative of a real sent subject.

5. Evaluate downstream outcomes responsibly

If comparing two concise subject variants, keep the audience, offer, sender and timing as stable as the program permits. Decide in advance what business outcome matters, such as qualified conversations or booked meetings, and use the same attribution window for both groups. Record exclusions and sample sizes. Do not call a variant a winner merely because it looks cleaner on one phone, and do not make a causal claim from two uncontrolled batches sent to different account segments.

Subject length is only one variable. A short subject can be misleading; a longer one can be crystal clear. If one version changes the claim, tone and recipient context along with length, the comparison cannot isolate the effect of character count. A better test changes as little as possible while preserving an honest description of the message. The FTC's accuracy requirement remains a constraint for every variant✓ . 6

FAQ

How we researched this

We read RFC 5322 for subject syntax and line limits, RFC 6532 for internationalized headers, RFC 2047 for encoded-words, Microsoft's subject and Exchange documentation, and FTC guidance on commercial-email subjects. Sources were checked October 1, 2026. They establish technical and accuracy constraints, but none establishes a universal best visible character count. This article therefore presents a display and testing process, not a fabricated benchmark✓ . 126

For help building a research-led outbound program, talk to Modern Inbound.