Este viernes, 13 de noviembre de 2026, text-wrap: balance pasa a ser Baseline Widely available. Web.dev define ese estado como 30 meses después de que una función funcione en todos los motores principales, y webstatus.dev fecha ese momento el 13 de mayo de 2024, cuando la sacó Safari 17.5. Es buena excusa para repasar los dos valores de text-wrap que arreglan los fallos tipográficos que todos hemos publicado alguna vez: titulares con una línea larga y otra minúscula, y párrafos que acaban con una palabra colgando sola.
El problema: el navegador solo mira una línea
Por defecto, el navegador corta el texto de forma voraz. Llena una línea hasta que la siguiente palabra no cabe, salta y sigue, sin mirar qué efecto tiene eso en las líneas de después. Es rápido y, para casi todo el texto, suficiente. Pero en un titular de tres líneas, como el de la demo, deja muchas veces una palabra sola en la última, y en un párrafo crea una última línea tan corta que parece un error.
Antes esto se arreglaba a mano con <br>, con entre las dos últimas palabras o con una librería de JavaScript que medía el texto. Todo eso se rompe en cuanto cambia el ancho, la fuente carga tarde o alguien edita el texto.
Dos valores, dos trabajos
text-wrap es un atajo de text-wrap-mode (wrap o nowrap) y text-wrap-style. Los valores interesantes están en la parte de estilo:
balancereparte el texto para que todas las líneas tengan más o menos el mismo número de caracteres. Está pensado para bloques cortos: titulares, pies de foto, citas destacadas.prettymantiene el corte normal, pero deja que el navegador use un algoritmo más lento que prioriza la composición frente a la velocidad. En la práctica, es lo que evita la palabra suelta al final de un párrafo.
Este es todo el CSS que usa el panel "Después" de la demo de arriba:
h1, h2, h3, blockquote {
text-wrap: balance;
}
p {
text-wrap: pretty;
}
Mueve el deslizador de ancho (o pulsa "Barrer") y fíjate en las barras: cada una es una línea real, medida con un Range por palabra y getClientRects(). A la izquierda, con wrap a secas, en muchos anchos el titular acaba con una última línea que apenas ocupa una quinta parte de la columna, marcada en naranja como "palabra suelta". A la derecha, balance iguala las líneas y la más corta suele ser dos o tres veces más larga. Puedes cambiar cada elemento entre wrap, balance y pretty para ver qué hace cada valor por separado.
Lo que balance no hace
balance cambia dónde se cortan las líneas, no el ancho de la caja. La documentación de Chrome avisa de que un titular equilibrado puede dejar hueco a la derecha, y eso queda raro dentro de una tarjeta con borde o fondo. Si te molesta, pon un max-inline-size al titular.
Además tiene un límite de líneas, porque equilibrar cuesta. Según MDN, solo actúa en bloques de seis líneas o menos en Chromium y de diez o menos en Firefox. A partir de ahí, el texto se corta como siempre. Por eso balance no tiene sentido en el cuerpo del texto: la propia guía de Chrome recomienda usarlo con criterio en los titulares y no en *.
Lo que hace pretty depende del navegador
La especificación deja las mejoras concretas en manos de cada navegador, y los dos motores que lo soportan hacen de verdad cosas distintas:
- Chrome añadió
prettyen la versión 117. Su blog dice que se centra en las huérfanas: evita una sola palabra en la última línea y ajusta las líneas anteriores para hacerle sitio. - Safari lo añadió en la versión 26. El equipo de WebKit explica que su implementación mejora todas las líneas del párrafo, no solo el final: iguala el borde irregular, evita líneas cortas y reduce los guiones. El mismo artículo dice que Chromium solo ajusta las cuatro últimas líneas.
En rendimiento, MDN avisa de que pretty tiene un coste y lo recomienda para textos en los que la composición importa más que la velocidad. El artículo de WebKit es más tranquilo: el número de elementos no influye, y harían falta párrafos de cientos o miles de líneas para notar algo.
Soporte y plan B
Según los datos de compatibilidad de MDN, balance funciona en Chrome y Edge 114, Firefox 121 y Safari 17.5. pretty funciona en Chrome y Edge 117 y en Safari 26, pero todavía no en Firefox.
Lo bueno es que no necesitas plan B. Si un navegador no conoce el valor, ignora la declaración y el texto se sigue cortando como siempre. No se rompe nada: solo se ve un poco peor. Si quieres saber en qué caso estás, como hace la demo para mostrar su aviso, es una línea:
const hasPretty = CSS.supports('text-wrap', 'pretty');
En Firefox, la demo detecta que pretty no está soportado, lo dice, y su párrafo se comporta como wrap, que es justo lo que verán tus usuarios.
Un detalle: si usas la propiedad larga, es text-wrap-style: balance, no text-wrap-mode, que solo acepta wrap y nowrap.
Qué vigilar
prettyen Firefox: hasta que llegue falta un tercio del panorama, aunque el plan B no cuesta nada.- Chromium y el resto del párrafo: si Chromium extiende
prettymás allá de las últimas líneas, como hizo WebKit, el resultado se parecerá más entre navegadores. avoid-short-last-line: ya aparece en la gramática detext-wrap-styleen MDN, pero los datos de compatibilidad de MDN no lo dan como soportado en ningún navegador, así que de momento no lo uso.