Si tu calendario no tiene marcado el 17 de noviembre de 2026, anótalo hoy. Ese día Chrome 158 llega a estable y el navegador deja de procesar XSLT para siempre. No es un rumor ni una propuesta en discusión: es una fecha fija en la documentación de Chromium, con un año de avisos en consola ya acumulados.
Qué se apaga exactamente
Dos cosas. La primera es la API de JavaScript XSLTProcessor, la clase que transformaba XML dentro de la página. La segunda es la instrucción xml-stylesheet con tipo text/xsl, la que llevan arriba los feeds RSS con hoja de estilos, los sitemaps decorados y una cantidad incalculable de interfaces viejas de routers, NAS y equipos industriales. Cuando entre en vigencia, cualquiera de esas páginas se va a renderizar como una pila de etiquetas crudas, sin nada de presentación.
Por qué lo matan
El argumento de Chrome es de seguridad y es sólido. El XSLT del navegador corre sobre libxslt, una librería en C de principios de los 2000 que procesa input controlado por un atacante dentro del proceso del renderer, que es justamente el que más dolores de cabeza da en memoria. La librería es vieja, susceptible a overflows, y su mantenedor de largo plazo abandonó el cargo en junio de 2025: quedó C de dos décadas, sin dueño, en el lugar más expuesto del navegador. Y su uso es marginal: una carga de cada 7.891 según las mediciones que cita Google, cerca del 0,001% del total.
Tampoco es Google decidiendo solo. La propuesta entró por el grupo de estándares, el issue de WHATWG se abrió el 1 de agosto de 2025, y tanto Firefox como WebKit declararon estar de acuerdo con la remoción. La diferencia es que Chrome tiene la fecha y los otros están esperando a ver qué se rompe.
Lo que no te va a avisar ninguna métrica
Aquí está la pega para los que administramos servidores: los buscadores nunca leyeron esas hojas de estilos, les da exactamente lo mismo el XML crudo. Por eso tu Analytics no va a mover un número ni un dashboard te va a disparar alerta alguna. La deprecación va a llegar en diciembre como un reclamo de un usuario que abrió tu feed y encontró caracteres sin formato. Con aparatos es peor: el XML de una impresora o de un panel de configuración no lo migras nunca más, y si se veía legible era gracias a esa hoja XSLT. Cuando desaparezca, nadie en tu inventario se va a dar cuenta hasta que algo explote.
El tiempo que te dejan
Hay dos válvulas de escape y ninguna dura para siempre. La política empresarial (XSLTEnabled) existe desde la versión 146, pero solo sirve en dispositivos administrados: para un sitio público no aplica. La origin trial se abrió con la versión 152 y compra nueve meses, con fin definitivo el 17 de agosto de 2027 en Chrome 176. Es tiempo de migración, no un permiso.
Las salidas razonables son tres. Mover la transformación al servidor, donde XSLT sigue funcionando sin problema — el que corre en tu pipeline de build ni se entera. Migrar el endpoint a JSON con render del lado del cliente. O usar un polyfill en WebAssembly si el XML original no se puede tocar. Y un detalle que pocos leen: la instrucción con tipo text/css sigue viva. Si tu XML solo necesita verse presentable sin reestructurarse, un CSS simple es la migración más barata que existe.
Inventario primero, navegador después
Mi opinión: la decisión me parece correcta y hasta tardía. Nadie extraña una librería C heredada dentro del renderer, y un 0,001% de uso no justifica el riesgo. Pero la lección para los que mantenemos infra es otra, y la dejo escrita: haz el inventario antes de que el navegador decida por ti. Un grep por text/xsl en tus carpetas web toma veinte minutos. Lo corrí esta mañana sobre mi propia flota: aparecieron un par de feeds con hoja XSLT y un panel viejo que dependía de eso. Una pega que me iba a llegar como reclamo en noviembre, resuelta antes del desayuno.
Fuente de inspiración: Removing XSLT for a more secure browser — Chrome for Developers
