Chrome 158 deja de ejecutar XSLT el 17 de noviembre de 2026, fecha programada al momento de publicar esta nota: si tu web convierte XML en una página dentro del navegador (un feed RSS con estilo, un sitemap que se ve como página, una app interna construida sobre XSLTProcessor), dejará de funcionar en Chrome. Aquí tienes cómo comprobarlo en cinco minutos y las tres salidas, ordenadas según cuánto tiempo te da cada una.
¿Qué es XSLT?
XSLT (Extensible Stylesheet Language Transformations) es un lenguaje para transformar documentos XML en otros formatos, normalmente HTML. Funciona con dos archivos: el XML con los datos y una hoja de estilo XSL (.xsl) con las reglas de conversión. Los navegadores lo incorporaron a principios de los 2000, pero todos se quedaron en XSLT 1.0, de 1999. El lenguaje siguió evolucionando por fuera, con XSLT 2.0 en 2007 y XSLT 3.0 en 2017, y nunca volvió al navegador.
¿Qué elimina Chrome 158 exactamente?
Desaparecen las dos formas que tiene el navegador de ejecutar XSLT: la instrucción de procesamiento que le dice al navegador que transforme un XML al abrirlo (<?xml-stylesheet type="text/xsl" href="...">) y la API de JavaScript XSLTProcessor.
El calendario, según el documento de deprecación de Chrome:
| Chrome | Fecha | Qué pasa |
|---|---|---|
| 143 | 2 dic 2025 | Deprecación oficial; avisos en la consola y en Lighthouse |
| 146 | 10 mar 2026 | Disponible la Enterprise Policy |
| 152 | 25 ago 2026 | Disponible el Origin Trial |
| 158 | 17 nov 2026 | XSLT deja de funcionar en Stable, salvo con Origin Trial o Enterprise Policy |
| 176 | 17 ago 2027 | Origin Trial y Enterprise Policy dejan de funcionar; XSLT queda desactivado para todos |
El argumento de Google es la seguridad: los navegadores solo implementaron XSLT 1.0 sobre código de parseo de XML envejecido y, según la medición de la propia Google, apenas alrededor del 0,02 por ciento de las cargas de página usa XSLT. Tampoco es una decisión solo de Chrome: el documento indica que Firefox y WebKit también apoyan retirar XSLT de la plataforma web, y Microsoft ya documenta la misma política temporal para Edge.
Un detalle que conviene saber: las notas de la versión 158 de Chrome no mencionan la eliminación. Al momento de publicar, el documento de deprecación es el único lugar oficial donde está escrita.
¿Me afecta si mi web usa XSLT?
Te afecta si es el navegador quien ejecuta la transformación:
- Sirves archivos XML (feeds, sitemaps, reportes, catálogos) con una línea
<?xml-stylesheet type="text/xsl"?>para que se vean como una página con estilo al abrirlos en Chrome. - Tu código de front-end llama a
new XSLTProcessor().
No te afecta el XSLT que corre en tu servidor: Java, .NET, la extensión XSL de PHP, libxslt en un paso de build. Tampoco afecta a los programas que leen tu XML sin mostrarlo en Chrome, como los lectores de feeds y los crawlers: nunca usaron el motor XSLT de Chrome.
¿Cómo saber si mi web usa XSLT?
1. Busca en tu código. Desde la raíz del proyecto:
grep -rn "xml-stylesheet\|XSLTProcessor" .
2. Escucha los reportes de deprecación. El documento de Chrome muestra cómo detectar el uso de XSLT con la Reporting API:
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
console.warn("XSLT en uso:", report.body);
}
});
}, {types: ["deprecation"], buffered: true}).observe();
Envía eso a tu sistema de logs en vez de a la consola y tendrás un inventario con tráfico real.
3. Prueba el futuro hoy. Desactiva XSLT en chrome://flags/#xslt y carga tus páginas. Lo que se rompa ahí es lo que se rompe el 17 de noviembre.
4. Si administras una flota de navegadores, el Legacy Technology Report de Chrome Enterprise muestra qué sitios internos todavía usan XSLT.
¿Cómo funciona el Origin Trial de XSLT y hasta cuándo dura?
El Origin Trial permite que tu sitio público siga usando XSLT nativo después de la eliminación. Registras tu origen en la consola de origin trials de Chrome, obtienes un token y lo sirves de una de estas dos formas:
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
Origin-Trial: TOKEN_GOES_HERE
El token solo funciona para el origen que registraste. Si sirves archivos XML directos con instrucción de procesamiento, no tienen <head> HTML, así que usa la cabecera HTTP.
El límite: termina con Chrome 176, el 17 de agosto de 2027. Son unos nueve meses después de la fecha de eliminación: tiempo para migrar, no una solución.
¿Cómo mantener XSLT con la política empresarial XSLTEnabled?
Si el XSLT vive en aplicaciones internas y tu empresa administra sus navegadores, la política XSLTEnabled mantiene XSLT disponible en esos equipos. Está disponible desde Chrome 146. Actívala desde tu consola de administración o con Group Policy y comprueba que se aplicó en chrome://policy.
Para Edge, Microsoft documenta la misma política (Edge 147 y posteriores) y la califica de temporal:
- Registro:
SOFTWARE\Policies\Microsoft\Edge - Valor:
XSLTEnabled, tipoREG_DWORD,0x00000001 - macOS: clave
XSLTEnabled, valor<true/>
El límite: solo cubre los navegadores que administras (tus visitantes públicos no la tienen) y en Chrome también deja de funcionar en la versión 176.
¿Hay un polyfill de XSLT para Chrome?
Sí, y cubre la mayor parte de XSLT 1.0. El polyfill al que remite el documento de Chrome, xslt_polyfill (paquete npm xslt-polyfill, licencia BSD-3-Clause), ejecuta libxslt y libxml2 compilados a WebAssembly y reimplementa la API XSLTProcessor completa. No depende de ningún trial, así que no tiene fecha de vencimiento.
Para código JavaScript que ya usa XSLTProcessor, carga primero el script y deja tu código como está:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
Para un archivo XML con instrucción de procesamiento, agrega una línea como hijo directo del elemento raíz:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
xmlns="http://www.w3.org/1999/xhtml"></script>
...content...
El script detecta la instrucción de procesamiento, ejecuta la transformación y reemplaza el documento. Según la guía de Chrome, esa línea no debería afectar a los lectores de RSS.
¿Cómo ver un XML con XSLT en Chrome después del 17 de noviembre?
Existe una extensión de Chrome que aplica el mismo polyfill a todas las páginas XML que usan XSLT. Es útil para los usuarios de una aplicación que no puedes modificar: instalan la extensión y el XML se sigue viendo como antes.
¿Qué limitaciones tiene el polyfill?
Su propio README las detalla con honestidad:
- Solo XSLT 1.0. Si necesitas 2.0 o 3.0, no es la herramienta.
- Solo mismo origen. Las URLs de otro origen y las
data:quedan bloqueadas incluso con cabeceras CORS. xsl:include,xsl:importydocument()se descargan de forma asíncrona, así que los métodos síncronos deXSLTProcessorfallan cuando una hoja de estilo los usa.- El archivo debe servirse como UTF-8, porque el WebAssembly va incrustado en el script.
- El XSLT nativo corre primero. Mientras tu Chrome todavía tenga XSLT, el polyfill nunca entra en acción: prueba con
chrome://flags/#xsltdesactivado o no estarás probando nada.
El autor lo describe como una solución provisional y recomienda SaxonJS para soporte real de XSLT.
¿Cómo convertir XML a HTML sin XSLT en el navegador?
La solución permanente es sacar la transformación del navegador. El documento de Chrome propone tres caminos:
- Transforma en el servidor y envía HTML terminado. Si ya tienes el
.xsl, cualquier motor XSLT del lado del servidor puede ejecutarlo. - Cambia el endpoint a JSON y renderízalo con JavaScript.
- Usa SaxonJS si necesitas XSLT en el cliente: es la biblioteca de XSLT en JavaScript más grande y soporta XSLT 3.0.
Para RSS y Atom en un sitio HTML, la recomendación es dejar de enlazar el XML de forma visible y declararlo en el <head>, que es donde lo buscan los lectores de feeds:
<link rel="alternate" type="application/rss+xml">
¿Qué opción elegir?
| Situación | Opción | Dura hasta |
|---|---|---|
| Sitio público que no alcanza a migrar antes del 17 | Origin Trial | 17 ago 2027 |
| App interna en navegadores administrados | Enterprise Policy | 17 ago 2027 (Chrome) |
| XSLT 1.0, mismo origen, sin tiempo para reescribir | Polyfill | Sin fecha fija; provisional |
| Todo lo que pienses mantener | Servidor, JSON o SaxonJS | Permanente |
El orden razonable: comprueba esta semana, usa el trial o la política si necesitas margen, y dedica esos nueve meses a mover la transformación a un lugar que no dependa del navegador.
¿Y tú? ¿Dónde tienes XSLT todavía: en un feed, en un sitemap o en una aplicación interna?
- Lo muevo al servidor o a JSON
- Polyfill mientras migro
- Origin Trial o política empresarial
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: Chrome DevTools MCP para agentes: lo probamos y así maneja diálogos y consola 
yoDEV Tested