Publicado: 29 de octubre de 2025
Chrome tiene la intención de dar de baja y quitar XSLT del navegador. En este documento, se detalla cómo puedes migrar tu código antes de que se quite a finales de 2026.
Chromium dio de baja oficialmente XSLT, incluidas la API de JavaScript XSLTProcessor y la instrucción de procesamiento XSLT. Tenemos previsto quitar la compatibilidad a partir de la versión 158 (17 de noviembre de 2026). Los proyectos de Firefox y WebKit también indicaron que planean quitar XSLT de sus motores de navegador. En este documento, se proporciona un poco de historia y contexto, se explica cómo quitaremos XSLT para que Chrome sea más seguro y se proporciona una ruta de migración antes de que estas funciones se quiten del navegador. Para conocer las actualizaciones más recientes, consulta también la entrada de Chrome Platform Status.
¿Qué se quitará?
Hay dos APIs en el navegador que implementan XSLT, y ambas se quitarán:
- La clase XSLTProcessor (por ejemplo,
new XSLTProcessor()). - La instrucción de procesamiento de XSLT (por ejemplo,
<?xml-stylesheet type="text/xsl" ... ?>).
Cronograma para Chrome
Chrome tiene el siguiente plan:
- Chrome 142 (28 de octubre de 2025): Se agregaron mensajes de advertencia anticipada a la consola de Chrome.
- Chrome 143 (2 de diciembre de 2025): Baja oficial de la API. Los mensajes de advertencia de baja comienzan a mostrarse en la consola y en Lighthouse.
- Chrome 145 (2 de diciembre de 2025, Canary): Las versiones Canary, Dev y Beta comienzan a inhabilitar XSLT de forma predeterminada, como advertencia anticipada.
- Chrome 146 (10 de marzo de 2026): Se lanza la política empresarial (EP) para realizar pruebas. Esto permite que las empresas prueben la inhabilitación de XSLT con anticipación y que sigan usando las funciones después de la fecha de eliminación.
- Chrome 152 (25 de agosto de 2026): Se lanza la prueba de origen (OT) para realizar pruebas. Esto permite que los sitios sigan usando las funciones después de la fecha de eliminación.
- Chrome 154 (22 de septiembre de 2026): Las versiones Canary, Dev y Beta de WebView comienzan a inhabilitar XSLT de forma predeterminada, como una advertencia temprana.
- Chrome 158 (17 de noviembre de 2026): XSLT deja de funcionar en las versiones estables para todos los usuarios, excepto los participantes de la prueba de origen y la política empresarial.
- Chrome 176 (17 de agosto de 2027): Dejan de funcionar la prueba de origen y la política empresarial. XSLT está inhabilitado para todos los usuarios.
¿Qué es XSLT?
XSLT, o transformaciones de lenguaje de hoja de estilo extensible, es un lenguaje que se usa para transformar documentos XML, por lo general, en otros formatos, como HTML. Usa un archivo de hoja de estilo XSLT para definir las reglas de esta conversión y un archivo XML que contiene los datos que se usan como entrada.
En los navegadores, cuando se recibe un archivo en formato XML que se vincula a una hoja de estilo XSLT, el navegador usa las reglas de esa hoja de estilo para reorganizar, dar formato y convertir los datos XML sin procesar en una página estructurada (a menudo, HTML) que se puede renderizar para el usuario.
Por ejemplo, una hoja de estilo XSLT podría tomar la siguiente entrada XML:
<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&quo>t<; hr>ef<=">demo.xsl" ?
<page
me>s<sage
> Hello World.
/message
/page
y esta hoja de estilo XSL:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Trans>for<m"
xsl:output meth>od=<"html"/
xsl:template m>atch=<&quo>t;/page</>message&q<uot;
body
pMes><sa>ge: x<sl:va>lue<-of select=&q>u<ot;."//p
> /body
/xsl:template
/xsl:stylesheet
y los procesa en este HTML para que el navegador lo muestre: HTML
<body>
<p>Message: Hello World.</p>
</body>
Además de la instrucción de procesamiento de XSL que se muestra en el ejemplo anterior, también está la API de JavaScript XSLTProcessor, que se puede usar para procesar documentos XML locales con hojas de estilo XSLT locales.
Historia de XSLT
El World Wide Web Consortium (W3C) recomendó XSLT el 16 de noviembre de 1999 como un lenguaje para transformar documentos XML en otros formatos, con mayor frecuencia HTML para mostrar en navegadores web. Antes de la recomendación oficial de la versión 1.0, Microsoft tomó una iniciativa temprana y lanzó una implementación de propiedad basada en un borrador de trabajo de W3C en Internet Explorer 5.0, que se lanzó en marzo de 1999. Siguiendo el estándar oficial, Mozilla implementó la compatibilidad nativa con XSLT 1.0 en Netscape 6 a fines del 2000. Otros navegadores importantes, como Safari, Opera y, más adelante, Chrome, también incorporaron procesadores nativos de XSLT 1.0, lo que convirtió las transformaciones de XML a HTML en el cliente en una tecnología web viable a principios de la década de 2000.
El lenguaje XSLT en sí siguió evolucionando con el lanzamiento de XSLT 2.0 en 2007 y XSLT 3.0 en 2017, que introdujeron funciones potentes, como expresiones regulares, tipos de datos mejorados y la capacidad de procesar JSON. Sin embargo, la compatibilidad con navegadores se estancó. En la actualidad, todos los motores de navegadores web importantes solo proporcionan compatibilidad nativa con el XSLT 1.0 original de 1999. Esta falta de avance, junto con el aumento del uso de JSON como formato de conexión y las bibliotecas y los frameworks de JavaScript (como jQuery, React y Vue.js) que ofrecen una manipulación del DOM y plantillas más flexibles y potentes, provocó una disminución significativa en el uso de XSLT del lado del cliente. Su función en el navegador web se sustituyó en gran medida por estas tecnologías basadas en JavaScript.
¿Por qué se debe quitar XSLT?
La inclusión continua de XSLT 1.0 en los navegadores web presenta un riesgo de seguridad significativo e innecesario. Las bibliotecas subyacentes que procesan estas transformaciones, como libxslt (usada por los navegadores Chromium), son bases de código de C/C++ complejas y antiguas. Este tipo de código es notoriamente susceptible a vulnerabilidades de seguridad de la memoria, como los desbordamientos del búfer, que pueden provocar la ejecución de código arbitrario. Por ejemplo, las auditorías de seguridad y los sistemas de seguimiento de errores identificaron repetidamente vulnerabilidades de gravedad alta en estos analizadores (p.ej., CVE-2025-7425 y CVE-2022-22834, ambos en libxslt). Dado que XSLT del lado del cliente ahora es una función de nicho que se usa con poca frecuencia, estas bibliotecas reciben mucha menos atención en cuanto a mantenimiento y seguridad que los motores principales de JavaScript, pero representan una superficie de ataque directa y potente para procesar contenido web no confiable. De hecho, XSLT es la fuente de varios exploits de seguridad mediáticos recientes que siguen poniendo en riesgo a los usuarios del navegador. Los riesgos de seguridad que implica mantener esta funcionalidad heredada y frágil superan con creces su utilidad moderna limitada.
Además, el propósito original de XSLT del cliente (transformar datos en HTML renderizable) se reemplazó por APIs de JavaScript más seguras, ergonómicas y con mejor mantenimiento. El desarrollo web moderno se basa en elementos como la API de Fetch para recuperar datos (por lo general, JSON) y la API de DOMParser para analizar de forma segura las cadenas XML o HTML en una estructura del DOM dentro de la zona de pruebas segura de JavaScript del navegador. Luego, los frameworks como React, Vue y Svelte administran la renderización de estos datos de forma eficiente y segura. Esta cadena de herramientas moderna se desarrolla de forma activa, se beneficia de la enorme inversión en seguridad en los motores de JavaScript y es lo que usan prácticamente todos los desarrolladores web en la actualidad. De hecho, solo alrededor del 0.02% de las cargas de páginas web actuales usan XSLT, y menos del 0.001% usa instrucciones de procesamiento de XSLT.
Esta no es una acción exclusiva de Chrome o Chromium: los otros dos motores de navegadores principales también admiten la eliminación de XSLT de la plataforma web: WebKit y Gecko.
Por estos motivos, dar de baja y quitar XSLT reduce la superficie de ataque del navegador para todos los usuarios, simplifica la plataforma web y permite que los recursos de ingeniería se enfoquen en proteger las tecnologías que realmente impulsan la Web moderna, sin pérdida práctica de capacidad para los desarrolladores.
Mejora la seguridad del análisis de XML
Al igual que los problemas de seguridad graves en libxslt, recientemente se informaron problemas de seguridad graves en libxml2, que se usa en Chromium para analizar, serializar y probar la correcta formación de XML. Para abordar futuros problemas de seguridad con el análisis de XML en Chromium, planeamos eliminar gradualmente el uso de libxml2 y reemplazar el análisis de XML por una biblioteca de análisis de XML con seguridad de memoria escrita en Rust. Es importante destacar que no quitaremos XML del navegador, sino que solo se considera quitar XSLT. Nuestra intención es garantizar que el reemplazo de libxml2 sea completamente transparente para los desarrolladores web.
No se quita XML + CSS
Es importante distinguir la baja de XSLT
(<?xml-stylesheet type="text/xsl" ... ?>) de la
instrucción de procesamiento <?xml-stylesheet ... ?> en sí, que sigue siendo compatible
cuando se usa con CSS. Puedes seguir usando la instrucción de procesamiento con
type="text/css" para aplicar reglas de diseño y diseño estándar a tus datos sin procesar,
tal como puedes hacerlo con HTML. Por ejemplo:
<?xml version="1.0" encodin>g<="UTF-8"?
?xml-stylesheet type="tex>t</css>&qu<ot; >href="s<tyles>.<css&q>uot;?
root
itemContent here/item
/root
Cómo realizar la migración
Existen algunas rutas alternativas para la migración.
JSON
Para los sitios que se compilan por completo en XML y XSL, no hay una forma única de realizar la transición. Las opciones de migración incluyen mover la canalización de procesamiento de XSLT al lado del servidor y enviar el HTML renderizado al cliente, o migrar los extremos de la API de XML del lado del servidor a JSON y realizar la renderización del lado del cliente con JavaScript para transformar JSON en HTML DOM y CSS.
XSLT del cliente en JavaScript
Existen algunas bibliotecas de XSLT del lado del cliente (basadas en JavaScript), pero la más grande, por mucho, es la que produce Saxonica (consulta la documentación completa de Saxonica). La implementación va mucho más allá de la implementación de XSLT 1.0 en los navegadores web, ya que implementa compatibilidad total con el estándar v3.0 más reciente y, con el tiempo, con el estándar v4.0 en curso.
Polyfill
Hay un polyfill que intenta permitir que el código existente, que depende de las implementaciones de XSLT 1.0 de los navegadores web, siga funcionando, sin usar las funciones nativas de XSLT del navegador. El polyfill se encuentra en GitHub.
El polyfill contiene un reemplazo funcional basado en WASM para la clase XSLTProcessor, por lo que el código JavaScript existente puede seguir funcionando tal como está:
<script src="xslt-polyfill.mi><n.js&qu>ot<;/scri>pt
script
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, d<ocument>);
/script
El polyfill también proporciona una función de utilidad automática para reemplazar de forma sencilla los documentos XML que usan instrucciones de procesamiento XSLT:
Para un archivo demo.xml original como este:
<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>ref="demo.xsl"?
ROOT
...content...
Se puede agregar una línea para invocar el polyfill y transformar el documento con la hoja de estilo XSLT a la que se hace referencia:
<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>r<ef="demo.xsl"?
ROOT
script src="xslt-polyfill.min.js"><
xml>ns="http://www.w3.org/1999/xhtml"/script
...content...
En este caso, el nuevo elemento <script> carga el polyfill, que detecta el
tipo de documento XML y la instrucción de procesamiento XSLT, y lo carga de forma transparente,
lo que reemplaza el documento.
Extensión
También hay una extensión de Chrome que se puede agregar a los navegadores compatibles, que aplicará el mismo polyfill de XSLT a todas las páginas XML sin procesar que contengan instrucciones de procesamiento de XSLT o llamadas a XSLTProcessor. Esto se puede usar para aplicaciones en las que no se puede cambiar el XML o XSLT de origen, para mantener la funcionalidad.
En particular, cuando se inhabilita XSLT, Chrome ahora muestra un banner de advertencia que vincula directamente a una página de búsqueda de extensiones para ayudar a los usuarios a encontrar una extensión:
Casos de uso específicos
En el debate sobre los estándares de HTML, se identificaron varios casos de uso concretos. En esta sección, se habla específicamente de cada uno de ellos para recomendar rutas de acceso para los desarrolladores que publican recursos XML que usan XSLT en la actualidad.
Feeds RSS y Atom
En muchos feeds RSS o Atom existentes, se usa XSLT para que los feeds XML sin procesar sean legibles por humanos cuando se ven directamente en un navegador. El caso de uso principal es que, cuando un usuario hace clic accidentalmente en el vínculo del feed RSS de un sitio, en lugar de pegar ese vínculo en su lector de RSS, obtiene una respuesta HTML con formato que puede leer, en lugar del XML sin procesar.
Existen dos caminos para este caso de uso. La forma "estándar" de HTML para hacerlo es agregar <link rel="alternate" type="application/rss+xml"> a un sitio (basado en HTML), en lugar de agregar un <a
href="something.xml"> explícito (visible para el usuario) en el que los usuarios podrían hacer clic accidentalmente. Esta solución permite
que los lectores de RSS encuentren el feed si un usuario pega solo la URL del sitio web, pero también
permite que los usuarios humanos vean el contenido HTML normal sin confundirse
con un vínculo a un recurso XML. Esto también sigue el paradigma web normal de que
HTML es para humanos y XML es para máquinas. Por supuesto, esto no resuelve el caso en el que un usuario simplemente "tiene" un vínculo RSS de algún lugar y lo pega en su navegador web (en lugar de su lector de RSS).
Cuando no se desea esa solución, el polyfill ofrece otra alternativa. Como se mencionó
anteriormente, el feed XML RSS/Atom se puede aumentar con una línea, <script
src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>,
que mantendrá el comportamiento existente de la transformación basada en XSLT a HTML.
Esto no debería afectar la capacidad del lector de RSS para seguir analizando el XML, ya que
<script> es un elemento secundario directo del elemento raíz.
Resultado de la API para dispositivos incorporados
Algunos dispositivos comerciales incorporados miden o generan datos XML para que los usuarios los consuman en la red local. Algunos de estos dispositivos lo hacen
generando un solo feed de datos XML que usa XSLT para transformarlo en un
formato HTML legible por humanos. Esto permite que la API se vea directamente en un
navegador sin necesidad de código adicional en el dispositivo o en el navegador.
Como este es un caso de uso muy específico de la aplicación, la forma de la solución
puede variar. En el caso de las aplicaciones en las que se puede actualizar el código fuente del dispositivo incorporado, podría funcionar cualquiera de las opciones descritas anteriormente (JSON, polyfill). Sin embargo, en particular, muchos de estos dispositivos son difíciles o imposibles de actualizar por varios motivos. En ese caso, la extensión probablemente sea la mejor opción, ya que permite que los navegadores cliente sigan leyendo los datos exactamente de la misma manera, sin modificar el dispositivo.
Plantillas diferidas para sitios web
A veces, los desarrolladores web usan XSLT en el cliente para aplicar lenguaje de marcado de presentación al lenguaje de marcado semántico, que funciona como un lenguaje de plantillas diferido que es independiente del ecosistema de JavaScript.
Existen dos soluciones para este problema más general. Para un sitio existente creado de esta manera, la solución más sencilla es agregar el polyfill para mantener la funcionalidad existente. O bien, realiza la transformación XSLT en el servidor y entrega el HTML resultante al cliente, en lugar del XML sin procesar. La solución a más largo plazo para esas propiedades sería migrar a un framework más moderno basado en JavaScript o JSON.
Si encuentras un problema específico en Chrome relacionado con esta baja de XSLT, informa un error aquí.
Cómo detectar el uso de XSLT
Por lo general, las funciones obsoletas, como XSLT, se pueden detectar en tu base de código de algunas maneras. En esta sección, se describen dos de ellas.
La API de Reporting
La API de Reporting es un mecanismo de informes genérico para que las aplicaciones web informen sobre varias funciones y condiciones de la plataforma, incluidas las funciones obsoletas. Para configurarlo de modo que informe sobre la baja de XSLT, se puede usar un fragmento de código como este:
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
// XSLT usage was detected - report it back here.
}
});
}, {types: ["deprecation"],buffered: true}).observe();
Consulta este código en acción en CodePen.
Informe de tecnología heredada para empresas
Para los administradores de una empresa, el informe de tecnología heredada se puede usar para recopilar automáticamente el uso de funciones obsoletas y, luego, informarlo de una manera fácil de usar. Consulta este artículo de Atención al Cliente de Google para obtener más información sobre cómo habilitar esta función.