Content Truncation Rules: How Every Platform Cuts Your Text — and How to Write for It

Every platform truncates differently — email subject lines at 50 characters, push notifications at 80, meta descriptions at 155. Here's the truncation rules for major platforms, how to implement word-boundary truncation in code, and using truncation as a deliberate writing technique.

By sadiqbd · June 9, 2026

Content Truncation Rules: How Every Platform Cuts Your Text — and How to Write for It

Every platform that displays your content truncates differently — and most developers don't test for it

A tweet. A meta description. An email subject line. A push notification. A product card. A search result. Each platform has its own truncation point, its own truncation behaviour (hard cut vs. word break vs. ellipsis), and its own character counting rules (some count bytes, some count characters, some count grapheme clusters, some count display pixels).

Writing content that works when truncated requires knowing those rules. Building interfaces that display content from users requires handling truncation gracefully in code. The text truncator makes it practical to test both.

Platform truncation rules

Email subject lines

Desktop clients: Gmail shows approximately 60–70 characters in the inbox list view. Outlook shows 50–60 depending on the preview pane configuration.

Mobile: most mobile email clients show 30–40 characters before truncation in the notification.

Preheader text: the second line of preview text (shown after the subject in many clients) contributes another 35–90 characters before being cut. The combined subject + preheader should ideally fit within 150 characters to be fully visible on most clients.

Practical target: 40–50 characters for the subject line ensures it displays fully on most clients including mobile.

SMS and push notifications

SMS: standard SMS messages are 160 characters (7-bit GSM encoding) or 70 characters (Unicode/emoji), beyond which messages are split into segments. Each additional segment costs an additional message unit.

Push notifications (iOS): approximately 65–100 characters for the notification body before truncation, depending on device model and whether a media attachment is included.

Push notifications (Android): approximately 80–100 characters before truncation.

Social media

Twitter/X: 280 characters total. URLs are shortened to t.co links that count as 23 characters regardless of actual URL length.

LinkedIn posts: 210 characters shown before "...see more" in the feed preview. Full text visible after clicking.

LinkedIn article titles: approximately 100 characters before truncation in feed display.

Facebook: approximately 200 characters before "See More" in the news feed.

SEO contexts

Google meta description: approximately 155–160 characters. Descriptions are truncated with an ellipsis beyond this. More precisely, the limit is ~960 pixels, which varies by character width.

Google title tag: approximately 55–60 characters (~580 pixels).

Google Search Console URL display: very long URLs may be truncated in the interface.

Product and UI contexts

Product card titles: highly variable by platform and design. Shopify product cards in default themes typically display 40–80 characters before overflow. Amazon product titles show 50–80 characters in list views.

Open Graph titles (social previews): 55–60 characters recommended before truncation.

App store descriptions: Google Play and Apple App Store show the first 80 characters before a "Read More" expansion.

The word boundary question

A hard character truncation cuts in the middle of a word: "The Complete Guide to..." becomes "The Complete Guide to C" at 23 characters. This is almost always wrong — it looks broken and loses the last partial word.

Most truncation implementations should truncate at a word boundary:

Find the last space before the character limit
Cut at that space
Add ellipsis if desired

Python:

def truncate(text, max_chars, ellipsis="..."):
    if len(text) <= max_chars:
        return text
    truncated = text[:max_chars - len(ellipsis)]
    last_space = truncated.rfind(' ')
    if last_space > 0:
        truncated = truncated[:last_space]
    return truncated + ellipsis

JavaScript:

function truncate(text, maxChars, ellipsis = "...") {
    if (text.length <= maxChars) return text;
    const truncated = text.substring(0, maxChars - ellipsis.length);
    const lastSpace = truncated.lastIndexOf(' ');
    return (lastSpace > 0 ? truncated.substring(0, lastSpace) : truncated) + ellipsis;
}

CSS (visual truncation, no content modification):

.truncate {
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
    max-width: 200px; /* or whatever the container width is */
}

CSS truncation is display-only — the full text is in the DOM and accessible to search engines and screen readers. This is often preferable to truncating the actual content.

The curiosity gap: truncation as a writing technique

Truncation is also a deliberate writing device. Email subject lines, article teasers, and social preview text are often crafted specifically to be compelling when truncated — the cut-off creates a curiosity gap that motivates the click.

The technique: end the visible portion on a partial thought, an unanswered question, or a surprising claim that needs explanation:

"We tested 47 EMI calculators and found that most of them get the formula wro..." → reader clicks to see what the formula gets wrong.

vs.

"How EMI is calculated: a guide to the standard formula for monthly installment..." → reader has seen the whole premise, may not click.

This is why copywriters test content at the exact truncation point — the emotional hook needs to land before the cut.

Multi-line truncation

Single-line truncation (text overflow) is straightforward. Multi-line truncation — showing exactly 2 or 3 lines of text with ellipsis at the end of the last line — is more complex:

CSS-only (modern):

.clamp {
    display: -webkit-box;
    -webkit-line-clamp: 3;  /* number of lines */
    -webkit-box-orient: vertical;
    overflow: hidden;
}

-webkit-line-clamp is now supported in all modern browsers without the prefix in most cases.

JavaScript approach (when CSS isn't sufficient): Calculate the height of one line, multiply by desired line count, and truncate the content until it fits within that height — then add ellipsis. More complex and performance-sensitive than CSS.

Unicode and character counting complications

Not all characters are equal in width or byte count:

Emoji: a single emoji may be 1 display character but 2–4 bytes in UTF-8 and 2 code units in JavaScript's UTF-16 internal representation. "😊".length in JavaScript returns 2, not 1.

East Asian characters: CJK characters (Chinese, Japanese, Korean) are typically full-width — each occupies roughly twice the horizontal space of a Latin character. A "60 character" limit may visually truncate much sooner for CJK text.

Combining characters: characters with combining diacritics (é composed as 'e' + combining acute accent) may count as 2 code points but display as 1 character. é.length in JavaScript depends on whether it's the precomposed or decomposed form.

For accurate character counting that matches visual display, use grapheme cluster counting rather than code point or code unit counting. Libraries like grapheme-splitter (JavaScript) handle this correctly.

How to use the Text Truncator on sadiqbd.com

Paste your text — the content to truncate
Set the limit — in characters or words
Choose word-boundary truncation — if available, preserves word integrity
Set the ellipsis — ... or … (U+2026) or empty
Copy — the truncated result, ready to test in its target context

Test the result: paste it into the actual interface where it will appear (email subject field, tweet draft, product title field) to verify it displays correctly at the real character rendering width.

Frequently Asked Questions

What's the difference between characters, bytes, and code points? Characters (graphemes) are what users see — one glyph. Code points are Unicode's numbering for each character. Bytes are the storage representation (UTF-8 uses 1–4 bytes per code point). For truncation purposes, characters are what you want to count, but many programming APIs count code points or bytes instead.

Should I truncate at the API level or the display level? Display-level CSS truncation is generally preferable — preserve the full content, control display. API-level truncation (actually shortening the stored string) is appropriate when storage or transmission has hard limits (SMS, API response size limits).

Is the Text Truncator free? Yes — completely free, no sign-up required.

Every platform will show your content differently at the boundary — planning for truncation rather than being surprised by it is the difference between professional content and content that feels unfinished.

Try the Text Truncator free at sadiqbd.com — shorten any text to an exact character or word limit, with word-boundary awareness and customisable ellipsis.