text-wrap: balance vs. pretty im Vergleich: Zeilenumbrüche endlich im Griff

1. Warum Zeilenumbruch überhaupt ein Problem ist

Der Standard-Zeilenumbruch im Web arbeitet nach einem einfachen, gierigen Algorithmus: Wörter werden so lange in eine Zeile gepackt, bis kein weiteres mehr passt, dann beginnt die nächste Zeile. Dieses Verhalten ist schnell zu berechnen, produziert aber regelmäßig hässliche Ergebnisse, etwa eine Überschrift, bei der nur ein einziges kurzes Wort in die letzte Zeile rutscht, oder einen Fließtext-Absatz, dessen letzte Zeile aus nur einem Wort besteht. text-wrap mit den Werten balance und pretty adressiert genau dieses Problem, ohne dass JavaScript oder manuelle <br>-Tags nötig wären.

Diese Umbruch-Probleme sind in der klassischen Print-Typografie seit Jahrzehnten bekannt und werden dort mit Zeilenumbruch-Optimierung durch professionelle Satzsoftware gelöst, die den gesamten Absatz global durchrechnet. Das Web hatte lange Zeit keinen Zugriff auf vergleichbare Algorithmen, weil CSS ausschließlich den gierigen Zeilenumbruch kannte. Mit text-wrap wandert ein Stück dieser Print-Qualität direkt in den Browser, ohne serverseitige Vorberechnung oder Build-Schritt.

Traditionell haben Designer solche Umbruch-Probleme entweder ignoriert oder mit hartkodierten Zeilenumbrüchen im Markup gelöst, was bei responsiven Layouts sofort bricht, sobald sich die verfügbare Breite ändert. Ein manueller <br> für Desktop sieht auf Mobilgeräten oft katastrophal aus. text-wrap löst dieses Problem deklarativ und responsiv, der Browser berechnet den optimalen Umbruch bei jeder Breite neu, ohne dass Entwickler für jeden Breakpoint eine eigene Lösung schreiben müssen.

Diese responsive Neuberechnung passiert automatisch bei jedem Reflow, etwa beim Drehen eines Mobilgeräts von Hoch- in Querformat oder beim Ändern der Fenstergröße auf dem Desktop, ohne dass ein zusätzlicher Event-Listener oder eine Media-Query-Abfrage nötig wäre.

Wichtig für das Verständnis: balance und pretty sind keine austauschbaren Synonyme für "schönerer Umbruch", sondern zwei Algorithmen mit unterschiedlichem Ziel und unterschiedlichen Einsatzgrenzen. Wer beide gleich behandelt, verschwendet einen der beiden Werte an der falschen Stelle im Layout.

Beide Werte sind Teil der breiteren CSS-Eigenschaft text-wrap, die zusätzlich die Werte wrap als Standardverhalten, nowrap zur vollständigen Unterdrückung von Umbrüchen und stable für konsistente Umbrüche während inkrementeller Textänderungen kennt. Für die typografische Feinarbeit sind jedoch balance und pretty die beiden praxisrelevanten Werte.

Historisch mussten Designer für ausgeglichene Überschriften auf JavaScript-Bibliotheken zurückgreifen, die per ResizeObserver die Breite eines Elements überwachten und bei jeder Größenänderung manuell Zeilenumbrüche einfügten. Diese Lösungen funktionierten, brachten aber zusätzliche Skriptlast, verzögerten den ersten Render und mussten bei jedem Redesign neu getestet werden. text-wrap löst dasselbe Problem nativ im Browser, ohne zusätzliches JavaScript und ohne Layout-Shift durch nachträgliche Umbruch-Korrektur.

2. text-wrap: balance im Detail

text-wrap: balance verteilt den verfügbaren Text so über alle Zeilen eines Blocks, dass jede Zeile eine möglichst ähnliche Länge hat. Der Browser berechnet dafür zunächst die Gesamtzahl an Zeilen mit dem Standard-Algorithmus und verteilt den Text dann so um, dass keine Zeile deutlich kürzer oder länger als die anderen ist. Das Ergebnis ist besonders bei mehrzeiligen Überschriften sichtbar: statt einer langen ersten Zeile und einem einzelnen Wort in der zweiten Zeile entstehen zwei ausgeglichene Zeilen.

balance ist explizit für kurze, prominente Textblöcke gedacht, also Überschriften, Hero-Claims, Zitate und Kartentitel. Der Algorithmus ist rechenintensiver als der Standard-Umbruch, weil er mehrere Umbruch-Varianten durchprobieren muss, um die ausgeglichenste Verteilung zu finden. Aus diesem Grund begrenzen Browser balance auf eine maximale Zeilenanzahl, für lange Fließtext-Absätze ist der Wert nicht gedacht und würde ohne dieses Limit spürbare Performance-Kosten verursachen.

/* balance evens out heading line lengths */
h1, h2, h3 {
  text-wrap: balance;
}

.hero-claim {
  font-size: clamp(1.75rem, 4vw + 1rem, 3rem);
  text-wrap: balance;
  max-width: 24ch;
}

/* Without balance: greedy wrap can leave one word alone
   "Modern web development for" / "ambitious teams" */
/* With balance: lines are evened out
   "Modern web" / "development for" / "ambitious teams" */

3. text-wrap: pretty im Detail

text-wrap: pretty verfolgt ein anderes Ziel als balance: statt alle Zeilen gleich lang zu machen, verhindert pretty gezielt einzelne, unschön isolierte Wörter am Ende eines Absatzes, sogenannte Hurenkinder oder Schusterjungen in der klassischen Typografie-Terminologie. Der Algorithmus betrachtet dafür mehr als nur die letzte Zeile und berechnet, ob ein anderer Umbruch weiter oben im Absatz das einsame letzte Wort verhindern kann, ohne die restlichen Zeilen merklich zu verlängern.

Weil pretty nicht versucht, jede Zeile gleich lang zu machen, sondern nur gezielt das letzte Zeilenproblem korrigiert, ist der Rechenaufwand geringer als bei balance und der Browser erlaubt pretty deshalb auch für lange Fließtext-Absätze ohne Zeilenlimit. Das macht pretty zur richtigen Wahl für Artikeltexte, Produktbeschreibungen und lange Absätze, während balance für kurze, prominente Textblöcke reserviert bleibt.

Der Name pretty ist bewusst allgemein gewählt, weil sich die genaue Heuristik zwischen Browserimplementierungen leicht unterscheiden kann, das übergeordnete Ziel bleibt aber immer dasselbe: keine einzelnen, optisch isolierten Wörter am Absatzende. Für Entwickler bedeutet das, sich nicht auf pixelgenau identisches Verhalten über alle Browser hinweg zu verlassen, sondern auf die grundsätzliche Verbesserung gegenüber dem Standard-Umbruch zu vertrauen.

/* pretty avoids orphaned single words in long paragraphs */
p, li, blockquote {
  text-wrap: pretty;
}

.article-body p {
  max-width: 70ch;
  text-wrap: pretty;
}

/* Without pretty: last line might read just "team."
   With pretty: the browser reflows earlier lines to avoid
   leaving a single orphaned word at the end */

Ein häufiges Missverständnis in Teams, die neu mit text-wrap arbeiten, ist die Annahme, pretty sei einfach eine schwächere Variante von balance. Tatsächlich sind es zwei komplett unabhängige Algorithmen mit eigener Spezifikation, keiner ist eine Untermenge des anderen. pretty kann in bestimmten Fällen sogar aufwendigere lokale Neuberechnungen vornehmen als balance bei einer sehr kurzen Überschrift, weil pretty potenziell mehrere vorangehende Zeilen mit einbezieht, um das Wortproblem am Ende zu lösen.

4. Der eigentliche Unterschied: Ziel und Algorithmus

Der Kernunterschied zwischen balance und pretty liegt im Optimierungsziel. balance optimiert global über den gesamten Block: alle Zeilenlängen sollen möglichst ähnlich sein. pretty optimiert lokal am Ende des Absatzes: nur das letzte Zeilenproblem soll gelöst werden, der Rest des Textes bleibt beim Standard-Umbruch. Diese unterschiedliche Zielsetzung erklärt, warum balance bei langen Absätzen unpraktikabel wäre, eine gleichmäßige Verteilung über zwanzig Zeilen zu berechnen wäre rechnerisch aufwendig und würde das Layout kaum sichtbar verbessern.

Für die praktische Arbeit reicht es, sich zu merken: balance denkt in Blöcken, pretty denkt in Zeilenenden.

Ein zweiter Unterschied betrifft die Zeilenanzahl-Begrenzung. balance ist von den Browserherstellern implizit auf wenige Zeilen begrenzt, üblicherweise irgendwo zwischen vier und zehn, abhängig von der Implementierung. Überschreitet ein Textblock dieses interne Limit, fällt der Browser automatisch auf den Standard-Umbruch zurück, ohne dass ein Fehler sichtbar wird. pretty kennt eine solche Begrenzung nicht und funktioniert unabhängig von der Textlänge, weil der Algorithmus nur lokal am Absatzende eingreift.

5. Das Sechs-Zeilen-Limit von balance verstehen

Die meisten Implementierungen von text-wrap: balance begrenzen die Berechnung intern auf ungefähr sechs Zeilen. Dieses Limit ist keine willkürliche Zahl, sondern eine bewusste Performance-Grenze: Der Balancing-Algorithmus muss mehrere mögliche Umbruch-Kombinationen durchprobieren, und die Anzahl der Kombinationen wächst mit der Zeilenanzahl stark an. Für eine dreizeilige Überschrift ist das trivial, für einen zwanzigzeiligen Absatz wäre es ein spürbarer Performance-Faktor beim initialen Rendering und bei jedem Reflow durch Fenstergrößenänderung.

In der Praxis bedeutet das: Wer balance versehentlich auf einen langen Fließtext-Absatz statt auf eine Überschrift anwendet, bemerkt keinen Fehler, sondern lediglich, dass der Effekt oberhalb der Zeilengrenze einfach nicht mehr greift und der Browser stillschweigend auf normalen Umbruch zurückfällt. Das macht Debugging schwieriger, weil kein Fehler und keine Warnung in der Konsole erscheint. Ein guter Anhaltspunkt in der Praxis: balance nur auf Elemente anwenden, die typischerweise nicht mehr als drei bis vier Zeilen haben, also Überschriften, Kartentitel und kurze Zitate.

Ein einfacher Test in den Entwicklertools hilft, diese Grenze schnell zu identifizieren: den Textinhalt eines Elements testweise stark verlängern und beobachten, ab wann die Zeilenverteilung wieder ungleichmäßig wird. Der Punkt, an dem das passiert, markiert die praktische Obergrenze für balance in diesem konkreten Layout und Font.

6. Beide Werte im selben Layout kombinieren

In den meisten echten Projekten kommen balance und pretty gemeinsam zum Einsatz, aber an unterschiedlichen Stellen im selben Layout. Eine typische Artikelseite setzt balance auf die Hauptüberschrift und alle Zwischenüberschriften, während pretty auf die Fließtext-Absätze angewendet wird. Diese Kombination adressiert beide Umbruch-Probleme dort, wo sie tatsächlich auftreten, ohne dass ein einziger Wert für beide Aufgaben zweckentfremdet werden muss.

Ein praktischer Ansatz für Designsysteme ist, die Zuweisung über Utility-Klassen oder direkt über Element-Selektoren zu automatisieren, statt bei jedem neuen Textblock manuell zu entscheiden. So bleibt die Regel konsistent im gesamten Projekt: Überschriften bekommen automatisch balance, Fließtext automatisch pretty, ohne dass ein einzelner Entwickler das bei jeder neuen Komponente erneut festlegen müsste.

Für Tailwind-basierte Projekte lässt sich diese Zuordnung außerdem direkt als Utility-Klasse abbilden, etwa text-balance und text-pretty, die intern genau die hier gezeigten text-wrap-Werte setzen. Das erlaubt es, die Entscheidung pro Komponente sichtbar im Markup zu treffen, ohne für jede Ausnahme eine zusätzliche CSS-Regel zu schreiben.

/* Typical project setup: balance for headings, pretty for body text */
h1, h2, h3, h4,
.card-title,
blockquote {
  text-wrap: balance;
}

p, li, dd,
figcaption,
.article-body {
  text-wrap: pretty;
}

/* Long headings automatically fall back to normal wrap
   once they exceed the internal line limit, no manual override needed */

Ein weiterer Vorteil dieser Trennung nach Element-Typ ist, dass sich die Regel automatisch auf neue Komponenten überträgt, sobald diese dieselben Klassen oder Selektoren verwenden. Ein neu hinzugefügtes Karten-Layout mit einer .card-title-Klasse erbt balance automatisch, ohne dass ein Entwickler die Regel erneut definieren muss, was Designsystem-Konsistenz über die Zeit erheblich erleichtert.

7. Fallback-Strategie für ältere Browser

Weil text-wrap: balance und text-wrap: pretty vergleichsweise neue CSS-Werte sind, ist eine defensive Fallback-Strategie sinnvoll, auch wenn beide Werte in einer Progressive-Enhancement-Weise funktionieren. Browser, die den Wert nicht kennen, ignorieren die gesamte Deklaration und behalten den Standard-Umbruch bei, es entsteht also kein Rendering-Fehler, sondern lediglich ein weniger optimierter, aber vollkommen funktionaler Zeilenumbruch. Genau deshalb lässt sich text-wrap ohne @supports-Abfrage produktiv einsetzen.

Für Projekte, die zusätzliche Kontrolle über die Zeilenanzahl-Begrenzung von balance brauchen, kann eine Kombination mit @supports (text-wrap: balance) sinnvoll sein, um gezielt alternative Stile für Browser ohne Unterstützung zu definieren, etwa eine engere max-width, die auch ohne Balancing-Algorithmus zu ausgeglicheneren Zeilen führt.

Ein weiterer Vorteil dieser Fallback-Strategie: Sie funktioniert unabhängig davon, ob der Nutzer einen aktuellen oder einen mehrere Jahre alten Browser verwendet, da die zugrunde liegende max-width-Begrenzung immer greift und nur bei unterstützenden Browsern durch die feinere Balancing-Berechnung ergänzt wird. Es entsteht also nie ein Zustand, in dem die Typografie objektiv schlechter aussieht als ohne text-wrap überhaupt.

/* Optional: tighter max-width as a fallback for browsers without support */
.hero-claim {
  max-width: 32ch;
  text-wrap: balance;
}

@supports (text-wrap: balance) {
  .hero-claim {
    max-width: 24ch; /* balance handles the rest */
  }
}

Für Redaktionssysteme lohnt sich außerdem, die Entscheidung zwischen balance und pretty nicht dem Redakteur zu überlassen, sondern über Content-Type-Templates zu erzwingen. Ein Blogartikel-Template setzt pretty automatisch auf jeden generierten Absatz, während ein Landingpage-Template balance auf alle Headline-Komponenten anwendet, unabhängig davon, welchen Text ein Redakteur später einträgt.

8. Performance und Reflow-Kosten

Sowohl balance als auch pretty verursachen zusätzliche Rechenkosten im Vergleich zum Standard-Umbruch, weil beide Algorithmen mehrere Umbruch-Varianten evaluieren, statt nur die erste passende zu übernehmen. Bei balance ist dieser Zusatzaufwand durch das Zeilenlimit begrenzt und in der Praxis für Überschriften und kurze Textblöcke nicht messbar. Bei pretty ist der Effekt noch geringer, weil nur die letzten Zeilen betrachtet werden.

Relevanter wird die Performance-Frage bei sehr dynamischen Layouts, etwa bei Textblöcken, die sich durch Nutzerinteraktion in Echtzeit in der Breite ändern, etwa beim Ziehen einer Sidebar. Jede Breitenänderung löst einen neuen Balancing-Durchlauf aus. Für die meisten Websites mit statischen oder responsive, aber nicht kontinuierlich veränderlichen Layouts ist dieser Aspekt vernachlässigbar, sollte aber bei Editor-artigen Interfaces mit Live-Resize im Hinterkopf behalten werden.

Messungen in echten Projekten zeigen, dass der Unterschied zwischen Standard-Umbruch und balance beim initialen Rendering typischer Überschriften im Bereich von Bruchteilen einer Millisekunde liegt, also weit unterhalb dessen, was ein Nutzer wahrnehmen könnte. Erst bei hunderten gleichzeitig balancierten Elementen auf einer einzigen Seite, etwa in einer sehr textlastigen Kachel-Übersicht, summiert sich der Effekt zu einer messbaren, aber immer noch geringen Gesamtzeit.

Ein weiterer Aspekt, der in der Praxis oft übersehen wird: Beide Werte arbeiten nur innerhalb des Block-Elements, auf dem sie deklariert sind, und interagieren nicht über Elementgrenzen hinweg. Eine Überschrift mit balance und der direkt folgende Absatz mit pretty werden vollkommen unabhängig voneinander berechnet, es gibt keine gemeinsame Optimierung über beide Blöcke hinweg. Das ist in der Praxis meist erwünscht, sollte aber beim Debugging ungewöhnlicher Umbruch-Ergebnisse berücksichtigt werden.

9. Anwendungsfälle im direkten Vergleich

Die Wahl zwischen balance und pretty ist keine Geschmacksfrage, sondern hängt direkt vom Element-Typ und der erwarteten Textlänge ab. Die folgende Übersicht zeigt, welcher Wert für welchen Anwendungsfall die bessere Wahl ist.

Die klare Regel lautet: balance für alles, was kurz und prominent ist, pretty für alles, was lang und fließend ist. Wer diese Grenze respektiert, bekommt in beiden Fällen sauberere Typografie, ohne an die interne Zeilenbegrenzung von balance zu stoßen oder die feineren Effekte von pretty auf zu kurzem Text zu verschwenden.

Für Grenzfälle, etwa eine dreizeilige Produktbeschreibung auf einer Kachel, lohnt sich ein kurzer Test in den Browser-Entwicklertools: Wird der Text mit balance tatsächlich gleichmäßiger, ohne die interne Zeilenbegrenzung zu überschreiten, ist balance die bessere Wahl. Wirkt das Ergebnis unverändert, weil das Limit bereits erreicht ist, sollte auf pretty gewechselt werden, das auch bei mehr Zeilen zuverlässig arbeitet.

10. Zusammenfassung

text-wrap: balance und text-wrap: pretty lösen zwei unterschiedliche Zeilenumbruch-Probleme mit unterschiedlichen Algorithmen. balance verteilt kurze Textblöcke wie Überschriften gleichmäßig über alle Zeilen und ist intern auf wenige Zeilen begrenzt. pretty verhindert gezielt einzelne Wörter am Ende langer Fließtext-Absätze, ohne Zeilenlimit und mit geringerem Rechenaufwand. Die richtige Kombination beider Werte im selben Projekt, balance für Überschriften und pretty für Fließtext, ersetzt manuelle <br>-Tags und JavaScript-Lösungen vollständig.

Wer diese Regel einmal im Designsystem verankert hat, profitiert bei jeder neuen Seite automatisch davon, ohne dass Redakteure oder Entwickler die Entscheidung erneut treffen müssen. Genau darin liegt der praktische Wert von deklarativem text-wrap gegenüber früheren, imperativen Lösungen.

Beide Werte funktionieren als Progressive Enhancement ohne @supports-Absicherung, weil ältere Browser die Deklaration einfach ignorieren und auf den Standard-Umbruch zurückfallen. Für neue Projekte lohnt sich, balance und pretty von Anfang an in die Basis-Typografie-Regeln eines Designsystems aufzunehmen, statt sie nachträglich pro Komponente zu ergänzen.

Am Ende bleibt die Kernaussage einfach: zwei Zeilen CSS ersetzen zuverlässig, was früher entweder gar nicht gelöst wurde oder aufwendige JavaScript-Bibliotheken erforderte, ein klarer Gewinn an Wartbarkeit ohne Kompromisse bei der visuellen Qualität.

Für Teams, die ein bestehendes Designsystem migrieren, empfiehlt sich ein schrittweises Vorgehen: zuerst pretty global auf alle Fließtext-Elemente anwenden, da hier das Risiko unerwarteter Layoutverschiebungen minimal ist, danach balance gezielt auf Überschriften-Komponenten ergänzen und dabei jede Komponente auf die interne Zeilenbegrenzung hin überprüfen. Dieses Vorgehen minimiert Überraschungen und macht die Umstellung in bestehenden Projekten risikoarm.

11. FAQ: text-wrap balance vs. pretty