Chrome removes XSLT support from Stable starting in version 158
XSLTProcessor and the XML stylesheet processing instruction stop working in Stable on 17 November. Chrome says XSLT shows up in just 0.02% of page loads.
Chrome is removing XSLT from the browser. From Chrome 158, which reaches Stable on 17 November, the XSLTProcessor JavaScript class and the XML stylesheet processing instruction stop working for everyone except sites enrolled in an Origin Trial or covered by an Enterprise Policy. Those exceptions run out at Chrome 176, due 17 August 2027, when XSLT is disabled for all users with no opt-out.
<?xml-stylesheet type="text/xsl" href="style.xsl"?>That line, and any JavaScript calling XSLTProcessor, silently stops transforming the page once Chrome 158 ships. Chrome’s own numbers put XSLT on about 0.02% of page loads, and it blames libxslt, the underlying C/C++ library, for a run of memory-safety bugs. Beta, Dev and Canary channels have already disabled XSLT by default since Chrome 145, so this has been visible for months to anyone testing ahead of Stable. Chrome points to a few ways to keep XML transforms working: move the transform server-side, swap in Saxonica’s JavaScript XSLT 3.0 implementation, or use its WASM-based polyfill, either directly or via a browser extension that applies it automatically.
Why it matters: if you’re still shipping client-side XSLT, anywhere from an old RSS stylesheet to a legacy enterprise XML pipeline, it breaks in Stable Chrome in nine days unless you’re on an Enterprise Policy. Worth a quick grep for xml-stylesheet and XSLTProcessor across your codebase before the 17th.