CSS text-wrap: balance & pretty Live Demo — Free Snippet

Ragged headlines have been a persistent design annoyance for as long as CSS has existed: a two- or three-line heading wraps greedily, filling each line to its maximum width before spilling the leftover words onto a final line — sometimes a single short "orphan" word sitting awkwardly by itself. Designers have historically fought this with manual <br> tags, JavaScript libraries like Shopify's balance-text, or by adjusting copy length until it "looked right." The CSS Text Module Level 4 property text-wrap finally solves this natively with two new values, balance and pretty, alongside the existing default, wrap.

How `text-wrap: wrap` behaves (the default)

Without any text-wrap declaration, browsers use a greedy line-breaking algorithm: text fills each line as full as possible before wrapping to the next, only breaking when a word would overflow the container width. This is fast to compute — the browser makes one pass — but it has no awareness of how the *last* line looks. A three-word overflow onto its own line, or a heading that reads "Design systems make teams move / faster" with an awkward break, is a common visual defect this algorithm produces.

How `text-wrap: balance` works technically

text-wrap: balance instructs the browser to compute multiple candidate line-break arrangements and select the one where line lengths are most evenly distributed, rather than the greedy first-fit. This is measurably more expensive to compute — which is exactly why the spec restricts it to blocks of a limited size, roughly four to six lines depending on the implementation, called the "balance limit." Beyond that limit, browsers silently fall back to normal greedy wrapping to avoid the performance cost of balancing large amounts of text. This makes balance ideal for headings, pull quotes, card titles, and button labels, but explicitly the wrong tool for multi-paragraph body copy.

How `text-wrap: pretty` differs

text-wrap: pretty uses a different, cheaper heuristic: rather than balancing every line's length, it specifically looks ahead to avoid orphans — a lone short word stranded on the final line — and other common typographic defects, without the computational cost of fully balancing the whole block. Because it's lighter weight than balance, pretty has no meaningful line-count limit and is designed to be used on body paragraphs, article text, and other longer-form content where full balancing would be too expensive or unnecessary.

Why this matters for 2025/2026 UI work

Before native text-wrap values, achieving balanced headlines required either shipping a JavaScript library that measures rendered text and injects <br> tags (causing layout thrashing and a flash of unbalanced text before the script runs), or manually hand-tuning breakpoints per viewport width — both fragile approaches that break the moment copy changes. text-wrap: balance and pretty move this entirely into the rendering engine: zero JavaScript, zero layout shift, and the balance recalculates automatically on every resize, font change, or content update, which is essential for CMS-driven or user-generated headings where you can't predict the exact text length in advance.

Browser support and the fallback strategy

text-wrap: balance shipped in Chrome 114, Safari 17.5, and Firefox 121; text-wrap: pretty is newer and, as of early 2026, has solid Chrome/Edge support with Safari and Firefox catching up. Because unsupported browsers simply ignore an unrecognized value and fall back to standard wrap behavior — never throwing an error or breaking layout — these properties are entirely safe to ship today as a progressive enhancement. This demo uses CSS.supports('text-wrap', 'balance') in JavaScript purely to report support status to the viewer; the CSS itself needs no @supports guard because the fallback is automatically graceful.