Chrome 158 deixa de executar XSLT em 17 de novembro de 2026, data programada no momento da publicação desta nota: se sua web converte XML em uma página dentro do navegador (um feed RSS com estilo, um sitemap que se parece com uma página, um app interno construído sobre XSLTProcessor), deixará de funcionar no Chrome. Aqui você tem como verificar em cinco minutos e as três saídas, ordenadas segundo quanto tempo cada uma lhe dá.
O que é XSLT?
XSLT (Extensible Stylesheet Language Transformations) é uma linguagem para transformar documentos XML em outros formatos, normalmente HTML. Funciona com dois arquivos: o XML com os dados e uma folha de estilo XSL (.xsl) com as regras de conversão. Os navegadores o incorporaram no início dos anos 2000, mas todos ficaram em XSLT 1.0, de 1999. A linguagem continuou evoluindo fora do navegador, com XSLT 2.0 em 2007 e XSLT 3.0 em 2017, e nunca voltou ao navegador.
O que o Chrome 158 elimina exatamente?
Desaparecem as duas formas que o navegador tem de executar XSLT: a instrução de processamento que diz ao navegador para transformar um XML ao abri-lo (<?xml-stylesheet type="text/xsl" href="...">) e a API de JavaScript XSLTProcessor.
O calendário, segundo o documento de descontinuação do Chrome:
| Chrome | Data | O que acontece |
|---|---|---|
| 143 | 2 dez 2025 | Descontinuação oficial; avisos no console e no Lighthouse |
| 146 | 10 mar 2026 | Política empresarial disponível |
| 152 | 25 ago 2026 | Origin Trial disponível |
| 158 | 17 nov 2026 | XSLT deixa de funcionar no Stable, exceto com Origin Trial ou Política Empresarial |
| 176 | 17 ago 2027 | Origin Trial e Política Empresarial deixam de funcionar; XSLT fica desativado para todos |
O argumento do Google é a segurança: os navegadores implementaram apenas XSLT 1.0 sobre código de análise de XML envelhecido e, de acordo com a medição do próprio Google, apenas cerca de 0,02 por cento dos carregamentos de página usa XSLT. Também não é uma decisão apenas do Chrome: o documento indica que Firefox e WebKit também apoiam remover XSLT da plataforma web, e Microsoft já documenta a mesma política temporal para Edge.
Um detalhe que vale saber: as notas da versão 158 do Chrome não mencionam a eliminação. No momento da publicação, o documento de descontinuação é o único lugar oficial onde está escrito.
Isso me afeta se minha web usa XSLT?
Te afeta se é o navegador quem executa a transformação:
- Você serve arquivos XML (feeds, sitemaps, relatórios, catálogos) com uma linha
<?xml-stylesheet type="text/xsl"?>para que fiquem com estilo ao serem abertos no Chrome. - Seu código de front-end chama
new XSLTProcessor().
Não te afeta o XSLT que corre no seu servidor: Java, .NET, a extensão XSL do PHP, libxslt em um passo de build. Também não afeta os programas que leem seu XML sem exibi-lo no Chrome, como os leitores de feeds e os crawlers: nunca usaram o motor XSLT do Chrome.
Como saber se minha web usa XSLT?
1. Procure em seu código. Desde a raiz do projeto:
grep -rn "xml-stylesheet\|XSLTProcessor" .
2. Escute os relatórios de descontinuação. O documento do Chrome mostra como detectar o uso de XSLT com a Reporting API:
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
console.warn("XSLT em uso:", report.body);
}
});
}, {types: ["deprecation"], buffered: true}).observe();
Envie isso para seu sistema de logs em vez do console e você terá um inventário com tráfego real.
3. Teste o futuro hoje. Desative XSLT em chrome://flags/#xslt e carregue suas páginas. O que quebrar aí é o que vai quebrar em 17 de novembro.
4. Se você administra uma frota de navegadores, o Legacy Technology Report do Chrome Enterprise mostra quais sites internos ainda usam XSLT.
Como funciona o Origin Trial de XSLT e até quando dura?
O Origin Trial permite que seu site público continue usando XSLT nativo após a eliminação. Você registra seu origin no console de origin trials do Chrome, obtém um token e o serve de uma destas duas formas:
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
Origin-Trial: TOKEN_GOES_HERE
O token funciona apenas para o origin que você registrou. Se você serve arquivos XML diretos com instrução de processamento, eles não têm <head> HTML, então use o cabeçalho HTTP.
O limite: termina com Chrome 176, em 17 de agosto de 2027. São aproximadamente nove meses após a data de eliminação: tempo para migrar, não uma solução.
Como manter XSLT com a política empresarial XSLTEnabled?
Se o XSLT vive em aplicações internas e sua empresa administra seus navegadores, a política XSLTEnabled mantém XSLT disponível nesses equipamentos. Está disponível desde Chrome 146. Ative-a desde seu console de administração ou com Group Policy e verifique que se aplicou em chrome://policy.
Para Edge, Microsoft documenta a mesma política (Edge 147 e posteriores) e a qualifica como temporal:
- Registro:
SOFTWARE\Policies\Microsoft\Edge - Valor:
XSLTEnabled, tipoREG_DWORD,0x00000001 - macOS: chave
XSLTEnabled, valor<true/>
O limite: cobre apenas os navegadores que você administra (seus visitantes públicos não a têm) e no Chrome também deixa de funcionar na versão 176.
Existe um polyfill de XSLT para Chrome?
Sim, e cobre a maior parte de XSLT 1.0. O polyfill ao qual o documento do Chrome se refere, xslt_polyfill (pacote npm xslt-polyfill, licença BSD-3-Clause), executa libxslt e libxml2 compilados para WebAssembly e reimplementa a API XSLTProcessor completa. Não depende de nenhum trial, então não tem data de vencimento.
Para código JavaScript que já usa XSLTProcessor, carregue o script primeiro e deixe seu 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 um arquivo XML com instrução de processamento, adicione uma linha como filho direto do 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...
O script detecta a instrução de processamento, executa a transformação e substitui o documento. De acordo com o guia do Chrome, essa linha não deveria afetar os leitores de RSS.
Como ver um XML com XSLT no Chrome depois de 17 de novembro?
Existe uma extensão do Chrome que aplica o mesmo polyfill a todas as páginas XML que usam XSLT. É útil para os usuários de um aplicativo que você não consegue modificar: eles instalam a extensão e o XML continua aparecendo como antes.
Que limitações o polyfill tem?
Seu próprio README as detalha com honestidade:
- Apenas XSLT 1.0. Se você precisa de 2.0 ou 3.0, não é a ferramenta.
- Apenas mesmo origem. As URLs de outro origin e as
data:ficam bloqueadas mesmo com cabeçalhos CORS. xsl:include,xsl:importedocument()são baixados de forma assíncrona, então os métodos síncronos deXSLTProcessorfalham quando uma folha de estilo os usa.- O arquivo deve ser servido como UTF-8, porque o WebAssembly vai embutido no script.
- O XSLT nativo corre primeiro. Enquanto seu Chrome ainda tiver XSLT, o polyfill nunca entra em ação: teste com
chrome://flags/#xsltdesativado ou você não estará testando nada.
O autor o descreve como uma solução provisória e recomenda SaxonJS para suporte real de XSLT.
Como converter XML em HTML sem XSLT no navegador?
A solução permanente é tirar a transformação do navegador. O documento do Chrome propõe três caminhos:
- Transforme no servidor e envie HTML pronto. Se você já tem o
.xsl, qualquer motor XSLT no lado do servidor pode executá-lo. - Mude o endpoint para JSON e renderize-o com JavaScript.
- Use SaxonJS se você precisa de XSLT no cliente: é a biblioteca de XSLT em JavaScript mais completa e suporta XSLT 3.0.
Para RSS e Atom em um site HTML, a recomendação é deixar de vincular o XML de forma visível e declará-lo no <head>, que é onde os leitores de feeds procuram:
<link rel="alternate" type="application/rss+xml">
Que opção escolher?
| Situação | Opção | Dura até |
|---|---|---|
| Site público que não consegue migrar antes de 17 de novembro | Origin Trial | 17 ago 2027 |
| App interno em navegadores administrados | Política Empresarial | 17 ago 2027 (Chrome) |
| XSLT 1.0, mesmo origin, sem tempo para reescrever | Polyfill | Sem data fixa; provisório |
| Tudo que você pensa em manter | Servidor, JSON ou SaxonJS | Permanente |
A ordem razoável: verifique esta semana, use o trial ou a política se precisar de margem, e dedique esses nove meses a mover a transformação para um lugar que não dependa do navegador.
E você? Onde você ainda tem XSLT: em um feed, em um sitemap ou em um aplicativo interno?
- Vou mover para o servidor ou JSON
- Polyfill enquanto migro
- Origin Trial ou política empresarial
- Prefiro outra opção (conte-nos qual)
Comente abaixo ou, se este artigo chegou até você por email, responda diretamente ao email: sua resposta é publicada aqui.
Relacionado: Chrome DevTools MCP para agentes: testamos e assim maneja diálogos e console 
yoDEV Tested