The CSS property text-box-trim gives authors a way to remove the unpredictable half-leading that sits above the first and below the last formatted lines of text. It is defined as part of the CSS Inline/Inline Layout specs and documented on MDN under text-box-trim and the related text-box and text-box-edge properties.
With text-box-trim you can make vertical spacing and alignment behave predictably across fonts, making padding, margins, gaps and visual rhythm consistent in UI components such as buttons, badges and inline icons. The property is a progressive-enhancement tool: use it where tight optical alignment matters and provide fallbacks for older browsers.
What text-box-trim does
At its core text-box-trim controls whether the “over” (top) and/or “under” (bottom) edges of a text element’s block container are trimmed. The property can remove the two half-leadings that create extra space outside the first and last lines of a formatted text run, producing a tighter box around the visible glyphs. The specification lives in the CSS Inline/Inline Layout modules and has accompanying docs on MDN.
The common explanation is simple: “This whitespace is called leading, and it appears above and below (so it’s two half-leadings, actually) all lines of text.” Removing that space optically aligns the top and bottom of text to chosen font metrics instead of the default line box padding. That helps when you want padding and margins to map to visual spacing, not font-specific leading.
Implementation relies on font metrics exposed by the browser. text-box-edge defines which metric to use—options include cap height, x-height, baseline, or visual glyph bounds—so trimming behaviour depends on OpenType metrics and how the user agent maps edge keywords to those metrics.
Why it matters for layout and rhythm
Different fonts carry different internal leading. Without trimming, two buttons with identical padding and font-size but different fonts can look misaligned vertically because half-leading adds unpredictable space above and below the text. Using text-box-trim makes that vertical rhythm consistent by tying the container edges to chosen font metrics instead of the line box overflow.
Chrome’s announcement summed it up with the line “The font knows, now CSS knows, too.” (Adam Argyle). In practice that means designers and developers can specify top and bottom alignment rules that behave predictably across typefaces, which simplifies design systems and grid alignment.
For UI components such as centered buttons, badges and tags, trimming enables visually centered text without fiddly per-font adjustments. It also improves alignment of inline icons with text and helps image-and-text combinations behave consistently across fonts and languages.
Syntax, values and quick patterns
The concise syntax for the trimming control is: text-box-trim: none | trim-start | trim-end | trim-both;. It is typically paired with text-box-edge (or the shorthand text-box) to choose which font metric the top/bottom edges should align to, for example cap, ex, text, alphabetic, or auto.
A common recipe to tightly align the top to cap height and the bottom to the baseline is:
text-box-trim: trim-both;
text-box-edge: cap alphabetic; / top to cap-height, bottom to baseline /
That pattern is copy/paste-ready for supported browsers, but remember to test across fonts because metrics like cap-height and glyph ink differ by face. Use trimming for visual polish and progressive enhancement: provide acceptable fallbacks when the property is unsupported.
Browser support and rollout advice
As of late 2025, text-box-trim has shipped in Chromium-based browsers and Safari: Chrome 133+, Edge 132+, and Safari 18.2+. Firefox has not implemented the property yet. Global usage share sits at roughly 69.6% according to StatCounter/CanIUse data (Oct 2025), which means many users will get the benefit but not all.
Because support is partial, adopt text-box-trim for non-critical layout elements now and use progressive enhancement for primary flows. Feature-detect at runtime or provide fallback CSS that tolerates the presence of half-leading (for example, slightly larger vertical padding or different alignment fallbacks) so Firefox and older browsers remain usable.
Keep an eye on implementation trackers: there are active Chromium and WebKit changes, Web Platform Tests, and Firefox Bugzilla requests. Tracking those repositories makes it easier to know when full cross-browser support arrives and whether any value-name or behaviour changes occur.
Practical examples, tooling and edge cases
Common UI patterns that benefit from trimming include vertically centered buttons, tags/badges with consistent padding, inline icon alignment, and tight line blocks. The Chrome blog and multiple example playgrounds demonstrate before/after scenarios showing how trim-both removes stray space and visually centers text without per-font offsets.
Interactive demos and community examples live in places like CodePen, the text-box-trim.vercel.app playground, and the jantimon/text-box-trim-examples repo. These examples cover buttons, badges, multi-font comparisons and icon alignment so you can see real-world effects before adopting the property in a design system.
Be aware of implementation details and edge cases: text-box-edge uses font metrics (cap height, x-height, baseline, glyph visual bounds) so behaviour depends on the font’s OpenType values. Trimming to visual glyph bounds (values like text or ideographic-ink) can differ in effect from alphabetic baseline trimming, and ideographic trimming for CJK scripts requires careful testing. Early implementations also differed in accepted values (older drafts used names that later changed), so consult the spec and browser notes when debugging.
Tooling is starting to catch up: there are requests and discussions to add support in Tailwind (discussion opened Apr 10, 2025) and Figma’s Design/Dev Mode has a vertical-trim concept that aligns with this feature. As design and dev handoffs standardize around trimmed vertical metrics, expect more mainstream tooling support.
When you roll out text-box-trim in a project, add component-level tests across representative fonts and languages, include graceful fallback styles for unsupported browsers, and keep a list of affected components so QA can check for regression across typography changes.
In short, text-box-trim is a small CSS affordance with outsized effects on visual rhythm and alignment. Use it carefully, test broadly, and prefer progressive enhancement until support becomes universal.
For detailed reading, consult the CSS Inline/Inline Layout spec, MDN articles for text-box, text-box-trim and text-box-edge, the Chrome Developers blog deep dive, CSS-Tricks explanations, and the jantimon examples repo and playgrounds for hands-on experimentation.
Adopting text-box-trim will help you get tighter, more consistent vertical typography in components where visual alignment matters. But remember: always feature-detect and provide graceful fallbacks so layouts remain robust in browsers that do not yet support the property.