Home / Blog / Chrome 157 Adds Custom Text-Overflow Strings
News
Chrome 157 Adds Custom Text-Overflow Strings
Chrome 157 reaches stable on November 3, 2026, and finally ships the text-overflow: <string> value — letting authors replace the default ellipsis with any marker they want. Firefox has had this since 2011. Safari still doesn't.
TL;DR: Chrome 157, scheduled for stable rollout on November 3, 2026, implements the <string> value for the text-overflow property, documented in Chrome Platform Status's release notes for version 157. Instead of the browser's default ellipsis character, authors can supply any string — text-overflow: " [more]" or text-overflow: "···" — to mark clipped text. It's a small addition with an unusually long backstory: Firefox has supported this exact syntax since version 9, back in 2011.
Truncated labels are everywhere in production interfaces — table cells, breadcrumb trails, file names, navigation items, product cards — and for most of the web's history, CSS only gave you one truncation marker: the single-dot ellipsis, or nothing at all. Teams that wanted a custom indicator, a localized affordance, or a brand-consistent symbol had to fake it with an absolutely positioned pseudo-element and a gradient mask over the text, which is fragile the moment font size, line height, or zoom level changes. Shops doing custom software development run into this constantly, because dense data tables and admin dashboards are exactly where truncation markers need to say something more specific than "…".
What Chrome 157 Actually Changes
Per Chrome Platform Status, the text-overflow property in Chrome 157 gains support for the <string> value defined in the CSS spec: in addition to the keywords clip and ellipsis, authors can now write text-overflow: "-"; or any other quoted string, which the browser renders inside the content box in place of the clipped text, shortening the visible text to make room. If there isn't enough space for the marker itself, the marker gets clipped too — the same graceful-degradation behavior the spec defines for the built-in ellipsis. Nothing about the clipping model changes: you still need overflow: hidden and a defined width or white-space: nowrap for truncation to kick in at all. This ships alongside Chrome 157's two-value text-overflow syntax, which lets a single declaration set independent start and end markers for cases like a horizontally scrollable label.
What This Means for Developers
The practical win is removing a workaround that's been standard practice for over a decade. If your design system needed a double-chevron, a localized "read more" affordance, or a brand glyph instead of "…", you were either stacking a pseudo-element with a background gradient to fake the clip, or living with the plain ellipsis everywhere. With native <string> support, that's one line of CSS, it respects the text's actual rendered width instead of an approximated mask, and it stays correct across font changes, zoom, and container resizing without extra JavaScript. The catch, per caniuse's compatibility data, is that Safari has never implemented this value — so it's still not a drop-in replacement if WebKit is in your support matrix; keep the gradient-mask fallback or accept the plain ellipsis there until that changes.
When Does This Ship
Chrome 157 is on Chrome Platform Status's release notes page with a scheduled stable channel rollout of November 3, 2026, following the standard beta-to-stable cadence after its mid-October beta. Firefox shipped the identical syntax in Firefox 9, back in 2011, which makes this one of the longer-lived cross-browser gaps for a feature this simple — not because the syntax was contentious, but because it sat low on Chromium's priority list for years while flexbox and grid-based truncation hacks papered over the gap for most teams.
Frequently Asked Questions
What does text-overflow: <string> actually do?
It replaces the default ellipsis character shown when text is clipped by overflow: hidden with a custom string of your choosing, such as " [more]" or a brand-specific glyph.
Do I still need overflow: hidden and white-space: nowrap?
Yes. text-overflow only controls what marker appears once text is already being clipped by those other properties — it doesn't cause truncation on its own.
Does Safari support the custom string value?
No, as of Chrome 157's release Safari has not implemented the <string> value for text-overflow, so cross-browser support still requires a fallback for WebKit.
Why did it take so long for Chrome to add this?
The syntax has been part of the CSS spec and supported in Firefox since 2011; it simply wasn't prioritized in Chromium until the 157 release cycle, despite being a small, uncontroversial addition.