Chrome elimina XSLT el 17 de noviembre: cómo auditar tu sitio y reemplazar las transformaciones del navegador

El 17 de noviembre de 2026, con la versión 158, Chrome deja de ejecutar XSLT: desaparecen la API JavaScript XSLTProcessor y la instrucción <?xml-stylesheet?> que convierte un XML en una página renderizada, y Firefox y WebKit han anunciado que seguirán la misma ruta. Si tu sitio sirve XML con hoja de estilo o tu JavaScript transforma feeds XML en HTML en el navegador, tienes poco más de un mes. La buena noticia: la auditoría son tres comprobaciones que caben en una tarde, existe un puente de emergencia (una origin trial que caduca el 17 de agosto de 2027) y, en la mayoría de los casos, el reemplazo correcto no es reescribir XSLT en JavaScript: es dejar de transformar en el navegador.

Qué se retira y cuándo

Son dos APIs, no una. La clase XSLTProcessor —cuando tu código llama a new XSLTProcessor() para transformar un XML en el cliente— y la instrucción de procesamiento <?xml-stylesheet type="text/xsl" ...?> en documentos XML de nivel superior —cuando es el propio navegador quien transforma al cargar el documento—. Chrome documenta el calendario completo de retirada:

No es una decisión de Chromium en solitario. Mozilla tiene un bug de seguimiento abierto para deprecar y retirar XSLT y su posición oficial en la discusión del WHATWG es que retirarlo es "bueno para la salud a largo plazo de la plataforma web y para la seguridad del usuario", señalando que el uso de XSLT es hoy inferior al que tenían las Mutation Events cuando se retiraron —y Flash, que se apagó, se usaba muchísimo más. WebKit, por su parte, ya añadió un aviso de deprecación en consola cada vez que un desarrollador usa una API de XSLT. Y Edge no se queda atrás: publicó la política XSLTEnabled para gestionar la transición y en la versión 147 ya retiró la producción de SVG con XSLT en línea.

El motivo declarado es seguridad. libxslt y libxml2 llevan años en modo mantenimiento y han sido origen repetido de incidentes; Chrome además planea migrar el parseo XML de libxml2 a un parser escrito en Rust. Cuando los tres motores coinciden en que una tecnología tiene que irse, la fecha deja de ser una recomendación.

Qué se rompe de verdad (y qué no)

No todo el mundo usa XSLT, y quien lo usa casi nunca lo sabe: suele venir de una plantilla heredada, de un widget de terceros o de un XML que alguien dejó de tocar hace una década. Estas son las cuatro clases que encontramos al revisar dependencias, en orden de gravedad:

La cuarta fila es la que más sustos va a dar en empresas: hay aplicaciones web internas que nadie ha tocado en años y que dependen de una hoja de estilo para mostrar siquiera su pantalla de login.

La auditoría: tres comprobaciones

Esta es la lista que añadimos al inicio de cualquier revisión de un sitio legacy antes de proponer una migración. No requiere acceso a nada especial.

1. Busca la firma en el código y en los XML que sirves. Un grep cubre el 90% de los casos:

grep -riE "xml-stylesheet|XSLTProcessor" --include="*.js" --include="*.xml" --include="*.xsl" --include="*.html" .

Revisa también los XML que entregas por HTTP —feeds, sitemaps, catálogos— buscando la instrucción <?xml-stylesheet?> en su cabecera.

2. Mira la consola de Chrome. Desde Chrome 143 aparecen avisos de deprecación de XSLT, y Lighthouse los reporta en sus auditorías. Este es el mejor detector de dependencias olvidadas: el aviso aparece aunque el XSLT venga de un widget de terceros que nunca tocaste, porque quien transforma es el navegador, no tu código.

3. Clasifica antes de decidir. No tiene sentido el mismo plan para un sitemap que para el login de una app interna:

Tres caminos de reemplazo (y un puente)

Una vez clasificado, el camino se elige con dos preguntas: ¿los datos cambian por usuario o por request? ¿Controlas el build?

Dos matices sobre el puente. El token de la origin trial se pide desde el panel de origin trials de Chrome, se inyecta por origen y funciona hasta Chrome 176 (17 de agosto de 2027); la enterprise policy sirve para entornos gestionados, que es el caso de los equipos internos. Sobre los polyfills: cubren razonablemente XSLTProcessor() cuando lo llama tu JavaScript, pero la instrucción declarativa en documentos de nivel superior es mucho más difícil de simular, y Mozilla lo discute abiertamente en su bug de seguimiento — hay una extensión polyfill en pruebas para Firefox, pero depender de una extensión del usuario no es una estrategia de producción.

Nuestra posición: no portees XSLT a JavaScript

Reescribir a mano cientos de líneas de XSLT —XPath 1.0, plantillas, modos, claves— con DOMParser es donde se atascan casi todos los proyectos de migración: es trabajo de semanas, no de días, y el resultado es código que nadie quiere mantener después. Nuestra regla es distinta. Si el XML y la XSL no cambian por usuario, mueve la transformación al build y guarda el HTML o el JSON ya resuelto. El sitio nuevo no debería saber que alguna vez hubo una transformación en tiempo de ejecución. Solo cuando el dato es vivo y no controlas la compilación tiene sentido transformar en el servidor; solo cuando la "transformación" es un mapeo de campos merece la pena DOMParser. Y el token de la origin trial se pide el día que no quedó otra opción, no el día que empezó el proyecto: es una grúa, y las grúas caducan el 17 de agosto de 2027.

Cómo lo encajamos en cada migración

Cuando sacamos contenido de un CMS legacy —la migración de WordPress a Astro de 2.500 páginas nos costó cinco días extra solo por formatos que ningún parser entendía—, la lista de "qué depende del navegador" ya era parte del diagnóstico. Lo que cambia ahora es la urgencia: antes, una transformación en el navegador era deuda silenciosa; el 17 de noviembre se convierte en una ruptura con fecha.

Por eso la revisión previa incluye el grep de arriba junto a las preguntas que ya hacemos sobre cómo se comporta el contenido sin JavaScript y dónde vive la lógica en una arquitectura en Cloudflare. Y si el sitio legacy tiene que seguir vivo unos meses más mientras migramos —ese fue justamente el caso de nuestro salto a Cloudflare Pages—, el puente de la origin trial compra tiempo, pero solo si lo pides antes del 17 de noviembre.

Antes del 17 de noviembre, en orden

1. Corre el grep en el repositorio y en los XML que sirves por HTTP.
2. Abre tus páginas con XML en Chrome y lee la consola.
3. Clasifica cada hallazgo en decorativo, funcional o crítico.
4. Para los funcionales: transformación en build, o en el servidor si el dato es vivo.
5. Para los críticos sin tiempo de migración: pide el token de la origin trial esta semana.

Cinco pasos, una tarde de trabajo en la mayoría de los sitios, y la diferencia entre descubrirlo el 17 de noviembre con los usuarios delante o descubrirlo ahora.