Sponsored

On 17 November 2026 Chrome 158 removes native XSLT. Two things stop working: the XSLTProcessor JavaScript API, and the <?xml-stylesheet?> processing instruction that makes a browser render an XML document through a stylesheet. Firefox and WebKit have said they will follow.

This is the index for everything on the subject. Start with whichever describes you.

“Chrome showed me a banner about XSLT”

That banner is a heads-up, not an error: the page still works today. Whether you were just visiting the page or it is your own site, what it means and what to do is here:

→ This site uses XSLT: what Chrome’s banner means

“I need to know whether this affects me”

Most sites are unaffected: XSLT runs in about 0.02% of page loads. The ones that are affected tend to be RSS and sitemap files with a stylesheet attached, intranet reports rendered client-side, and documentation toolchains. Who breaks, what it looks like when it does, and the honest trade-offs between a WASM polyfill, moving the transformation to the server, and precompiling at build time:

→ Chrome is removing XSLT: what breaks and what to do

“My RSS feed has a stylesheet on it”

This is the most common single case, and the least dangerous — a feed with <?xml-stylesheet?> keeps working as a feed. Only the human-readable rendering goes away:

→ Your RSS feed’s stylesheet stops rendering

“I want to check my stylesheets still work”

Whatever path you pick, the transformation stops being the browser’s job and becomes yours. That means running your stylesheets against a real processor. XSLT Playground runs XSLT 1.0, 2.0 and 3.0 on Saxon and XSLTC server-side, so it is a straight check of whether a stylesheet written for the browser still does what you think it does — and the 1.0 stylesheets written for XSLTProcessor are exactly the ones worth re-checking, because browser XSLT was always 1.0 and slightly its own dialect.