How to use CSS line-clamp to trim lines of text

If you’ve ever needed to limit an element’s line count without resorting to JavaScript, the line-clamp CSS property can help. It’s a handy way to rein in user-created content, keep cards neatly aligned, or prevent text from breaking a layout.

In simple terms, line-clamp limits the number of lines in a block container to a specified amount (as long as it isn’t multi-column). When clamping occurs, the overflowing text is cut off and replaced with an ellipsis (…) to signal there’s more to read. There’s no built-in toggle for expanding the text, but it’s a clean and lightweight approach for layout control.

In this article, you’ll learn how to use line-clamp effectively across browsers, what quirks to watch out for, and how it impacts UX and accessibility.

Why use line-clamp?

The property can be useful in multiple scenarios: trimming user-generated text, ensuring consistent card layouts, or even gating content behind a paywall.

For example, to constrain user-created content:

See the Pen line-clamp user content by Daniel Schwarz (@mrdanielschwarz) on CodePen.

Or to align card layouts more neatly:

See the Pen line-clamp cards by Daniel Schwarz (@mrdanielschwarz) on CodePen.

Or even to truncate an article preview for a paywall:

See the Pen line-clamp paywall by Daniel Schwarz (@mrdanielschwarz) on CodePen.

Despite its usefulness, line-clamp comes with several quirks ranging from browser inconsistencies to subtle UX flaws, and requires a specific set of companion properties to work correctly.

How to use line-clamp (cross-browser solution)

In a perfect world, you could simply write line-clamp: 2; to limit text to two lines. In Chromium browsers like Chrome, Edge, and Opera, that works fine, even though documentation on MDN or Can I use… still suggests otherwise. In practice, you’ll need a few extra properties to ensure consistent results across browsers.

Here’s a working, cross-browser implementation:

p {
  /* Safari & Firefox */
  -webkit-line-clamp: 2;
  display: -webkit-box;
  -webkit-box-orient: vertical;
  overflow: hidden;

  /* Chromium */
  line-clamp: 2;
}

This setup uses both the vendor-prefixed and unprefixed versions side by side. Firefox supports the WebKit-prefixed syntax, so this works across all major browsers.

If you prefer cleaner, conditional code, you can use the @supports at-rule:

p {
  @supports (line-clamp: 2) {
    line-clamp: 2;
  }

  @supports not (line-clamp: 2) {
    -webkit-line-clamp: 2;
    display: -webkit-box;
    -webkit-box-orient: vertical;
    overflow: hidden;
  }
}

That said, the first approach is safer since browser support for the unprefixed line-clamp property is still evolving.

Customizing or replacing the ellipsis

Unfortunately, there’s no built-in way to customize or remove the ellipsis (…) generated by line-clamp. The text-overflow property doesn’t apply, since it only affects inline overflow. Even using text-overflow: clip doesn’t work here.

The proposed block-ellipsis property may eventually allow developers to style or replace the ellipsis, but for now, it’s not supported. You also can’t append a “Read more” link inside the same container — it would appear after the clamped content, which isn’t visible.

There’s no elegant workaround yet, though some developers experiment with overlays or fading masks. For now, it’s best to embrace the built-in ellipsis or design around it.

The UX flaws of line-clamp

While line-clamp looks great visually, it raises some subtle UX and accessibility issues.

• Find-in-page: Browser search still detects clamped text even though it’s hidden, confusing users who can’t scroll to it.
• Screen readers: Clamped content is accessible to assistive tech, which can cause mismatched expectations if you’re intentionally hiding part of the content (like a paywall).
• SEO: Search engines can index clamped text since it remains in the source, potentially showing hidden content in snippets.

In short, line-clamp trims content visually but not semantically. That may be acceptable for aesthetic use cases but problematic for excerpts or gated content.

---

Over 200k developers use LogRocket to create better digital experiences

Learn more →

---

How line-clamp can improve UX

Despite those limitations, line-clamp can enhance visual clarity and readability when used intentionally.

In card layouts, it keeps descriptions uniform, allowing users to scan more content at once:

See the Pen line-clamp cards by Daniel Schwarz (@mrdanielschwarz) on CodePen.

When applied to user-generated content, it prevents layout breaks from overly long bios or messages:

See the Pen line-clamp bios by Daniel Schwarz (@mrdanielschwarz) on CodePen.

And when used creatively, it can even enforce paywall previews across multiple nested elements by applying line-clamp to the parent <article>:

See the Pen line-clamp article by Daniel Schwarz (@mrdanielschwarz) on CodePen.

This trick is rarely documented, but it’s a clever way to handle multi-element excerpts.

Alternatives to line-clamp

One alternative involves using line-height units to simulate a clamp:

p {
  max-height: 3lh; /* equal to roughly three lines of text */
  overflow: hidden;
}

This approach avoids vendor prefixes and non-standard syntax but lacks a native ellipsis. Some developers fade the last line with a gradient, but it’s less precise than line-clamp, which trims exactly at the character boundary.

The verdict

The goal of line-clamp is simple — limit visible text to a fixed number of lines. It’s an elegant, browser-native way to tidy up layouts and manage unpredictable content. But while it works visually, it’s not yet perfect for accessibility or SEO.

The ellipsis is still non-customizable, and browser support, though improving, remains uneven. The upcoming block-ellipsis property may address some of these gaps in the future.

Until then, line-clamp remains the best option for multi-line truncation. It’s reliable enough for production use — just be aware of its quirks before depending on it for critical UX flows.

Is your frontend hogging your users' CPU?

As web frontends get increasingly complex, resource-greedy features demand more and more from the browser. If you’re interested in monitoring and tracking client-side CPU usage, memory usage, and more for all of your users in production, try LogRocket.

LogRocket lets you replay user sessions, eliminating guesswork around why bugs happen by showing exactly what users experienced. It captures console logs, errors, network requests, and pixel-perfect DOM recordings — compatible with all frameworks.

LogRocket's Galileo AI watches sessions for you, instantly identifying and explaining user struggles with automated monitoring of your entire product experience.

Modernize how you debug web and mobile apps — start monitoring for free.