Last updated:
Business Email Length: Subject Line and Body Best Practices
The length of a business email directly affects whether it gets read and acted upon. Too long, and recipients skim or defer it. Too short, and you may come across as curt or unclear. Like writing effective Slack messages, being mindful of character count helps you communicate with precision. Subject lines get cut off by the recipient's display width, and bodies inflate once they are encoded into bytes. This article covers how to decide length with both of those in mind.
Email Technical Specifications and Character Count
Section 2.1.1 of RFC 5322 (Internet Message Format, 2008), the specification that defines the format of an email message, states that a line must not exceed 998 characters excluding the CRLF, and recommends keeping lines within 78. Because non-ASCII text is MIME-encoded, the visible character count and actual data size diverge. For example, a single UTF-8 CJK character consumes 3 bytes, and Base64 encoding inflates that by about 1.37x (4/3 plus the line folding) - so 1,000 Japanese characters produce about 4.1 KB of data. The same RFC imposes no explicit character limit on the Subject header, but as noted in our newsletter writing guide, the recipient's client display width is the practical constraint.
Encoding Methods and Actual Data Size
Email subject lines and body text undergo encoding that changes their data size. The same text can vary significantly in size depending on the encoding method - an important consideration when dealing with mail server size limits or header length restrictions.
| Encoding Method | Per CJK Character | Subject of 20 CJK Characters | Primary Use |
|---|---|---|---|
| ISO-2022-JP (Base64) | ~2.7 bytes (2 bytes x 4/3) | 82 bytes | Japanese business email |
| UTF-8 (Base64) | ~4 bytes (3 bytes x 4/3) | 92 bytes | International email, Gmail |
| UTF-8 (Quoted-Printable) | ~9 bytes (3 bytes x 3) | 192 bytes | Some email clients |
Subject headers are encoded using the RFC 2047 (MIME Part Three, 1996) encoded-word format (=?charset?encoding?encoded-text?=). The figures in the table above are complete header lengths, including the charset declaration and any character-set switching sequences. The four-character Japanese subject 会議の件, for example, becomes =?ISO-2022-JP?B?GyRCMnE1RCRON28bKEI=?= at 38 bytes under ISO-2022-JP + Base64, and =?UTF-8?B?5Lya6K2w44Gu5Lu2?= at 28 bytes under UTF-8 + Base64.
UTF-8 coming out smaller on a short subject is counterintuitive, but ISO-2022-JP has to wrap the non-ASCII run in character-set switching sequences and its charset name is longer. That overhead is fixed no matter how long the subject is, so it only pays for itself once the difference between 2 bytes and 3 bytes per character outweighs it - somewhere around 12 characters, beyond which ISO-2022-JP is the smaller of the two. RFC 2047 also caps a single encoded-word at 75 characters and a header line containing one at 76, so a long subject is split into several encoded-words and folded with CRLF plus a space.
In practice, older mail servers and gateways that fail to reassemble those folded headers correctly may truncate or garble long Subject headers. With UTF-8 + Quoted-Printable, a 50-character non-ASCII subject reaches roughly 450 bytes in the encoded payload alone, so keeping subjects under 50 characters is technically sound as well as practically effective.
Optimal Subject Line Length
For English-language emails, 30–50 characters is the ideal subject line range. The key thing to understand is that there is no fixed number of characters a client will show. On desktop mail software the user can resize the message-list column freely, so the same client displays wildly different amounts. The practical floor is set by devices with a fixed screen width - phones and wearables.
| Client / Device | What Determines Subject Width | Preview Text |
|---|---|---|
| Outlook Desktop | Message-list column width (widen it and more shows) | Hidden by default (can be enabled) |
| Gmail (Desktop) | Window width - subject and preview share a single line | Shown in gray after subject |
| Apple Mail (Desktop) | Column width, and a two-line layout can be enabled | Displayed on the line below the subject |
| iPhone (Portrait) | Fixed by screen width - considerably shorter than desktop | 1–2 lines below subject |
| Android Gmail | Fixed by screen width - considerably shorter than desktop | Shown below the subject |
| Apple Watch | Fixed by screen width - the shortest of all | None |
As with push notification character limits, placing the most important keywords within the first 30 characters of your subject line is critical.
Why 30–50 characters? A desktop list will usually show the whole subject, while a phone truncates it from the end. Keeping your subject within 30–50 characters is the "greatest common denominator" length: the full text appears on desktop, and the core of the message still survives on mobile. Since business email is often triaged on a phone first, that is the safer baseline to design around.
Rather than reaching for an outcome metric like open rate, it is easier to decide on a length by asking what is left once the subject is truncated. Here is how each length band tends to appear:
| Subject Length | How It Appears in a Phone List | Typical Problem |
|---|---|---|
| Under 20 characters | Shown in full | "Quick question" gives no way to judge topic or priority |
| 20–29 characters | Shown in full | Either the project name or the actual request gets dropped |
| 30–50 characters | Mostly in full; the tail may clip on some devices | Almost none, as long as the request comes first |
| 51–70 characters | The tail starts to be cut | A deadline or request placed at the end disappears |
| Over 70 characters | The second half is cut off entirely | Opening with boilerplate hides the request completely |
What this table really shows is that the part left standing after truncation matters more than the length itself. A 70-character subject causes no trouble if the request is already complete within the first 30 characters. A 45-character one that opens with "[Acme Corporation] Notice" leaves a phone user with no idea what it concerns, and it gets pushed down the queue.
Preview Text Optimization
Gmail and iPhone mail apps display the opening portion of the email body as "preview text" after the subject line. It is the last chance to explain yourself before the message is opened, and the place to add what the subject line could not carry.
Many business emails begin with a greeting like "Hi [Name], I hope this email finds you well." - which fills that space with pleasantries rather than substance. Putting your conclusion or deadline in the very first sentence is often enough for the subject and preview together to convey the whole picture.
For HTML emails, a common technique is to set hidden preheader text using <div style="display:none; max-height:0; overflow:hidden;">. This lets you control the preview text independently of the visible body. However, you must insert enough invisible whitespace characters (‌ repeated) after the preheader - otherwise, the visible body text will appear appended to the preheader in the preview.
How much preview text appears is also left to the client. In Gmail on the desktop the subject and the preview share a single line, so the shorter the subject, the more room the preview gets. On a phone the preview is confined to one or two lines under the subject, which is far less than on the desktop. To make it work everywhere, put the most critical information in the preview's first sentence and treat everything after it as optional.
Body Length Guidelines
Appropriate body length varies by email type. The guidelines below work backwards from the effort the message asks of the person reading it:
| Email Type | Word Count | How the Recipient Reads It |
|---|---|---|
| Quick confirmations | 50–100 words | Read without scrolling and handled on the spot |
| Requests and reports | 100–200 words | About the limit that still reads in one pass on a phone |
| Proposals and explanations | 200–300 words | Needs undivided attention, so it tends to be deferred |
| Detailed reports | 300+ words | Skimmed past in the body (better split into an attachment) |
Long emails are avoided not because of the word count itself, but because the reader has to hunt through the text for what they are supposed to do. The same 300-word email is light work when the request and the deadline come first, and never gets finished when the request sits at the end of a long account of the background. So when a draft runs long, try reordering it before cutting it: move the request to the top and push the details down.
Optimal Length by Email Category
Business emails, marketing emails, and transactional emails have fundamentally different length requirements.
| Email Category | Subject | Body | Design Focus |
|---|---|---|---|
| Internal business | 30–40 chars | 50–200 words | Convey the point quickly |
| External business | 35–50 chars | 100–300 words | Balance courtesy and brevity |
| Marketing email | 30–45 chars | 100–250 words | Short path to CTA |
| Transactional email | 35–55 chars | 50–150 words | Complete info, concisely |
| Newsletter (plain text) | 35–50 chars | 200–500 words | Minimize scrolling |
| Newsletter (HTML) | 35–50 chars | 100–300 words | Balance images and text |
What Happens When You Get the Length Wrong
Email length missteps can erode professional trust. Here are common patterns to avoid:
- Subject line says only "Hi" or "Hello" - recipients can't gauge priority without knowing the topic. Executives processing dozens of emails tend to deprioritize messages with vague subjects. In the worst case, it gets flagged as spam.
- Body exceeds 500 words - when the recipient has to scroll repeatedly to reach the end, the actual request gets buried somewhere in the text. For lengthy content, put the key points and the request in the body and move the background and reference material into an attachment.
- Body is under 10 words - "Got it" or "Understood" may seem efficient, but it can feel dismissive to clients or senior colleagues. A brief additional line makes a significant difference in tone.
- Subject-body mismatch - a subject reading "Please Confirm" paired with a body that only reports information without listing any confirmation items causes confusion and delays action.
HTML vs. Plain Text Email Size
The same content in HTML format versus plain text can differ dramatically in data size. HTML emails include markup tags, CSS, and image references, often resulting in 3–10x the data volume of plain text.
A practical consideration: in HTML emails, the visible character count and source code character count diverge. For example, "bold text" appears as 9 characters on screen but is <strong>bold text</strong> - 26 characters in the HTML source. When managing character counts for marketing emails, judge by the displayed text, not the source.
Additionally, a multipart/alternative email that carries both an HTML and a plain text version is sending the same content twice, so the data volume simply grows. Mail servers and sending services impose a per-message size limit, and that limit differs from one environment to the next. In image-heavy HTML email, the attached and embedded images dominate the total far more than the body text does, so when the limit is a concern, start by reviewing the images.
4 Tips for Emails That Get Read
- Make the subject line specific. Avoid vague subjects like "Quick Question." Use "[Action Required] Q3 Project Progress Report" instead. Adding a category tag in brackets at the start helps recipients instantly assess priority.
- Lead with the conclusion. Busy recipients need the key point immediately - don't bury it in the third paragraph. Ideally, the first two lines should state what you need and when you need it.
- Keep paragraphs to 2–3 sentences. Long blocks of text get skipped, especially on mobile where a 3-line desktop paragraph wraps to 6–7 lines.
- Use bullet points for multiple items. Lists are scanned 2–3x faster than prose paragraphs.
Pro Email Techniques
Professionals who handle dozens of emails daily rely on these strategies:
- Aim for "subject-line-complete" emails. A subject like "[Update] Client A meeting moved to 3/10 2 PM" conveys the full message without the recipient even opening the email - the ultimate time-saver.
- Apply the BLUF principle (Bottom Line Up Front). This military-origin technique puts the conclusion first, followed by context: "Request: Please approve the Q3 budget. Reason: Deadline is Friday." Busy readers grasp the point in two lines.
- Follow the "5-sentence rule." Targeting five sentences or fewer naturally produces concise, focused emails. If you can't fit it in five sentences, consider a phone call or meeting instead.
- Minimize quoting in replies. Full-text quoting just adds scrolling. Quote only the relevant portion and write your response directly below it.
Commonly Overlooked Edge Cases
When thinking about email character count, you need to manage more than just the body text:
- Signature length: Signatures typically run 3–5 lines (50–100 characters), but adding department, title, phone, and URL can push them past 200 characters. Even a 100-word body feels long when the signature adds another 150 characters. Keep signatures minimal.
- CC/BCC and header size: Every address you line up in CC inflates the email header by that much. Header lines are subject to a per-line character limit too, so the recipient field ends up folded across many lines, making it awkward both to display and to work with when replying. Once the list of recipients grows, consider a mailing list instead.
- Attachment filename length: Long filenames with non-ASCII characters can grow several times over under MIME encoding, and depending on the environment they may be truncated or garbled. Keep filenames just long enough to identify the file, then append only a date or a version number.
- Reply quote accumulation: Threads that have gone back and forth many times can build up tens of thousands of characters of quoted text. The per-message size limit is set by each environment, so even a short message can bump into it through accumulated quotes and signatures alone. Once a thread gets long, the safe move is to start a fresh email that summarizes where things stand.
Emoji in Subject Lines: Encoding Pitfalls
Using emoji in subject lines to stand out has become common in marketing emails, but there are technical pitfalls. Emoji are represented using Unicode surrogate pairs or combining character sequences, making them larger than regular characters when encoded.
For example, "🎉" (party popper) consumes 4 bytes in UTF-8 and roughly 8 bytes after Base64 encoding. A skin-tone emoji (e.g., 👋🏻) is made of two code points - the base emoji plus a skin-tone modifier - for 8 bytes in UTF-8. Emoji that join several emoji together with a ZWJ (Zero Width Joiner), such as the family and profession sequences, grow further because the joiners count too. Flag emoji (e.g., 🇺🇸) are a pair of Regional Indicator Symbols and also come to 8 bytes. It is safest to assume that anything that looks like one character can cost several characters' worth of bytes.
The issue goes beyond size. ISO-2022-JP cannot represent emoji, so subject lines containing emoji are forced into UTF-8 encoding. If the recipient's mail client expects ISO-2022-JP, the subject may display as garbled text. Older generations of mail software and some carrier email services may replace emoji with "□" or "?". For business emails, avoid emoji entirely. For marketing emails, consider your audience's email environment before using them.
Client-Specific Display Behavior
The same email renders differently across clients. Gmail displays preview text in gray after the subject - the shorter the subject, the more preview space is available. Outlook on the desktop can be configured to leave preview text off entirely, in which case the subject alone decides whether the email gets opened. Apple Mail can show the preview across several lines under the subject, so relatively more information arrives before the message is opened. Since these differences come down to the recipient's own settings and are beyond the sender's control, the practical answer is a 30–50 character subject plus the key point in the opening sentence, which holds up in any environment.
Email Newsletter Length
For email newsletters, plain-text format works best at 200–500 words, while HTML newsletters should target 100–300 words of copy. Keep the layout concise to minimize scrolling and prevent post-open abandonment.
Does Sending Time Change the Ideal Length?
Fixed rules like "short in the morning, longer in the afternoon" rest on open-rate statistics that are hard to verify and that shift from one audience to another. A more dependable habit is to keep the request within the first few lines no matter when you send. If you suspect timing really matters for your readers, compare the responses to a shorter and a longer version of the same message instead of trusting fixed hour bands.
Conclusion
Effective email communication balances brevity with clarity. Keep subject lines within 30–50 characters, and adjust body length to match the email's purpose. Understanding encoding differences, client-specific display behavior, and preview text optimization lets you design emails that work reliably across every environment. Attending to details like emoji encoding and preheader text removes still more of the moments where the recipient has to stop and work out what is being asked. Use Character Counter to check your email length before sending.