CSS text-overflow: ellipsis Hides Text — It Doesn't Remove It: When to Truncate at Display vs Data Layer

The CSS text-overflow: ellipsis property truncates what's displayed but doesn't change the DOM — the full text is still in the page source, still selectable, and still accessible to search engines and screen readers — which is completely different from server-side truncation that actually shortens the stored or served content

The previous articles on this site covered platform truncation rules, database VARCHAR data loss, pagination vs "read more," and UTF-8 boundary truncation issues. This article addresses CSS text truncation vs content truncation — the architectural choice between truncating at the display layer vs the data layer, and the specific scenarios where each is appropriate.

CSS truncation: display-layer hiding vs data-layer truncation

text-overflow: ellipsis is the most common CSS truncation technique:

.card-title {
  white-space: nowrap;      /* Prevent wrapping */
  overflow: hidden;          /* Hide overflowing text */
  text-overflow: ellipsis;   /* Show "..." at the cut point */
}

What this does: the full text content is in the DOM. The CSS prevents it from wrapping, hides the overflow, and shows … at the point where text is cut. If you inspect the element, the full text is there. If you select and copy the text, you get the full text. Screen readers may read the full text (depending on implementation and ARIA configuration).

What it doesn't do: truncate the actual content. The database still stores the full title. The API still returns the full text. The page source contains the full text.

Server-side truncation (cutting the string before rendering) is different — the full text never reaches the client. Database queries return truncated strings; API responses contain shortened text; the HTML contains only the partial content.

When display-layer truncation is appropriate

CSS truncation is correct when:

The full content is legitimately "there" and accessible: a card-based layout where each card shows a title in a fixed-height box. The full title exists; the CSS just prevents it from overflowing the card. A "Read more" link takes the user to the full content.

Accessibility is handled: if CSS hides content that matters to screen reader users, aria-label or alternative text should expose the full content. A button that shows "Submit fo..." (truncated) with aria-label="Submit form" is accessible; a button that just shows a truncated label is not.

The truncation is purely presentational: sorting by title, searching content, and meta description are all based on full content — the visual truncation doesn't affect any of these.

Multi-line CSS truncation: the WebKit clamp

Single-line text-overflow: ellipsis is straightforward. Multi-line truncation is more complex:

.card-description {
  display: -webkit-box;
  -webkit-line-clamp: 3;          /* Show maximum 3 lines */
  -webkit-box-orient: vertical;
  overflow: hidden;
}

-webkit-line-clamp (now supported in all major browsers, despite the vendor prefix) clamps text to a specified number of lines, showing … at the cut point. This is widely used in card grids, news feeds, and any layout where text blocks need uniform height.

The limitation: line-clamp shows a fixed number of lines — the actual character count depends on font size, container width, font family, and rendering platform. The same text with the same line-clamp: 3 shows more or fewer words on a wide desktop vs a narrow mobile screen.

For SEO and content metadata: if the truncated card description is also used as the meta description or og:description, always use the server-side generated (potentially separately-specified) meta description rather than the CSS-displayed truncated version.

The <details> and <summary> alternative to "Read more" truncation

For content where accessibility and SEO matter, the <details>/<summary> HTML pattern provides semantically meaningful collapsing without JavaScript:

<details>
  <summary>The first sentence of a long paragraph that introduces the topic.</summary>
  The rest of the content that's hidden until the user expands it...
</details>

What this achieves:

• All content is in the DOM (good for SEO — Googlebot can read the full text)
• Screen readers announce the expandable nature (<summary> is a focusable element)
• No JavaScript required — the expand/collapse behaviour is native HTML
• The open attribute controls default state

Where it's less suitable: card grids where uniform height is required (the expand behaviour breaks the layout grid), or where the visual design doesn't match the <details> disclosure triangle convention.

Truncation in search results and meta descriptions

The most widely-misunderstood truncation case is meta descriptions — because the question "how long should my meta description be?" is actually two separate questions:

1. How long will Google display before truncating? (~150-160 characters for desktop, shorter on mobile)
2. How long should the actual meta description be?

The answer to #2 is: as long as it needs to be to fully describe the page — Google truncates for display but reads the full text for relevance assessment. A meta description of 300 characters that fully describes the page may serve better than a 155-character version that's cut to fit the display limit — because Google may choose to display a different, relevant excerpt from the page content anyway.

Practically: write the most informative 150-160 characters, knowing it fits within the typical display window. Don't stuff the description with keywords just because more text can be written.

How to use the Text Truncator on sadiqbd.com

1. For server-side truncation generation: the tool generates the truncated string at the server level — appropriate for database storage, API responses, email subjects, and any context where the full text shouldn't reach the client
2. For determining truncation points: if you need to know exactly where a string is cut at character 160 (meta description) or character 255 (database column), the tool shows the exact cut point and the resulting truncated string
3. For CSS vs server-side decision: if the use case is purely visual layout (card titles, table cells), CSS truncation is more flexible and preserves the full content; if the use case involves data storage, API limits, or content that must be shortened for downstream systems, use server-side truncation via this tool

Frequently Asked Questions

If CSS truncation leaves the full text in the DOM, can search engines see the hidden content? Yes — Google reads the full DOM content regardless of CSS visibility. Content hidden by overflow: hidden, text-overflow: ellipsis, display: none, visibility: hidden, or height: 0 is accessible to Googlebot and is treated as page content (though content that requires user interaction to reveal, like collapsed <details>, was historically treated as somewhat less prominent). This is relevant for cases where you're considering hiding verbose content for layout reasons — if the content is legitimate and relevant, hiding it with CSS doesn't make it invisible to search engines. However, deliberately hiding content that isn't shown to users (showing content to search engines but not to users via CSS tricks) violates Google's quality guidelines and is treated as cloaking.

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

Try the Text Truncator free at sadiqbd.com — truncate any text to a precise character or word limit with word-boundary and ellipsis options.