Chrome 157 went stable on November 3, and one small CSS change in it is surprisingly handy: text-overflow now accepts a custom string, not just ellipsis or clip.
That means the "…" at the end of truncated text can be anything you want: " (more)", " →", " [...]".
It's listed in the Chrome 157 release notes. Firefox has supported it for years, since Firefox 9. Safari doesn't support it yet, according to MDN's compatibility data.
I tried it out before writing this. Here's the recipe, plus two things that caught me out.
The basic recipe
text-overflow only works on text that's already overflowing on a single line. So you still need the usual two properties alongside it:
.truncate { white-space: nowrap; /* keep it on one line */ overflow: hidden; /* hide what doesn't fit */ text-overflow: " (more)"; /* the new part */ } That's it. The browser cuts the text where it overflows and adds your string at the end.
Add a fallback in one line
Browsers that don't understand the string value ignore the whole declaration. So declare ellipsis first and let the newer value override it:
.truncate { white-space: nowrap; overflow: hidden; text-overflow: ellipsis; /* Safari and older Chrome use this */ text-overflow: " →"; /* Chrome 157+ and Firefox use this */ } Nobody gets a broken layout. They just get the classic "…" instead.
Gotcha 1: it cuts words in half
This was the first surprise. The cut happens wherever the text runs out of room, even mid-word. In my test, " (more)" produced:
Free shipping on every order over $50 unti (more)
The default ellipsis does the same thing, but it's easier to miss with "…". A word like "(more)" or "[...]" right after a broken word looks more like a bug.
Short, symbol-style markers like " →" or " …" hide this best.
Gotcha 2: multi-line clamping ignores it
The common way to show two or three lines and then cut off is -webkit-line-clamp. I paired it with the custom string:
.clamp { display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; overflow: hidden; text-overflow: " (more)"; } In Firefox, the custom string was ignored and the text ended with a normal "…". MDN's text-overflow page also says the property only affects text overflowing in the inline direction, not text cut off at the bottom of a box.
So this feature is for single-line truncation. I couldn't test Chrome 157's behaviour with line-clamp myself, so check it before relying on it.
What it can't do: be clickable
The string is just text drawn by the browser. You can't link it, focus it or attach a click handler.
So if you want an actual "Read more" that expands the text, you still need a real <a> or <button>. Where the custom string helps is as a visual hint, for example in table cells, card titles or file lists where the full text sits in a tooltip or detail view.
Where I'd actually use it
- Card and list titles:
" →"hints there's more to see. - Table cells:
" [...]"reads more clearly than "…" in dense data. - Non-English interfaces: you can use a marker that suits the language.
The quick reference
| Situation | Does the custom string work? |
|---|---|
Single line with nowrap and overflow: hidden | Yes (Chrome 157+, Firefox) |
| Safari | No, falls back to your ellipsis |
Multi-line with -webkit-line-clamp | Firefox ignored it in my test |
| Making the marker clickable | No, use a real link or button |
Small feature, but it removes a whole category of "add a custom suffix in JavaScript" code. Has anyone found a good use for the two-value form, where you set a different marker at the start and end of the line?

