Chrome 158 switches off XSLT for most users on 17 November

Chrome 158 switches off XSLT for most users on 17 November

18 October 2026: Chrome 158 reaches the Stable channel on 17 November 2026, and from that release XSLT stops working for everyone except organisations that turn it back on through the XSLTEnabled enterprise policy and sites enrolled in Google's origin trial. Both escape routes close with Chrome 176, scheduled for 17 August 2027, after which XSLT is gone from Chrome. Google says only about 0.02% of page loads use XSLT at all, but many of the ones that do sit inside business systems.

What stops working

Two things are removed. The first is the XSLTProcessor JavaScript class, used by web apps to transform XML in the page. The second is the XSLT processing instruction, the <?xml-stylesheet type="text/xsl" ...?> line that tells a browser to turn a raw XML file into a readable page. Google's figure for that second use is under 0.001% of page loads.

XML itself stays, and so does the same processing instruction with type="text/css", so an XML file styled with CSS will keep rendering. Google gives security as the reason: Chromium relies on libxslt, an ageing C library, for these transforms, and its platform status entry notes that the library went without a maintainer for about six months of 2025. Google also plans to replace libxml2 in Chromium with an XML parser written in Rust.

Where business systems still use it

Google's own list of affected cases is the useful one for an IT team. RSS and Atom feeds often carry an XSLT stylesheet so that someone who clicks the feed link sees a formatted page. Commercial embedded devices on local networks that measure or generate data often serve it as a single XML feed and leave the browser to turn it into a page, and Google notes that many of them are difficult or impossible to update. Some older sites use client-side XSLT as a templating layer, applying presentation to semantic markup outside any JavaScript framework.

Each of these will show raw XML in Chrome 158 or later unless something changes. When XSLT is disabled, Chrome shows a banner that links to an extension search.

The routes Google offers

• set the XSLTEnabled policy to keep XSLT on for managed browsers until Chrome 176
• enrol a public site in the origin trial, which also ends with Chrome 176
• add Google's WebAssembly polyfill, which replaces XSLTProcessor and can be loaded with one script line inside an XML document
• install the Chrome extension built on that polyfill for devices whose XML output cannot be changed
• move the transform to the server, or switch the endpoint to JSON and render it in JavaScript

Administrators can find affected pages before the switch through Chrome's Legacy Technology Report, and developers can catch deprecation reports with a ReportingObserver watching for the id XSLT.

Edge follows a month later

Microsoft Edge, built on the same engine, makes the same change in Edge 159 from mid-December, with its policy also ending at version 176; we covered that in our Edge item. Google says the Firefox and WebKit projects also plan to remove XSLT, though neither has given a date, so the policy setting buys time but does not make the migration optional.

Related on TrustList:

• Drupal fixes critical Field UI flaw with a no-login path via add-ons
• Microsoft Edge will switch off built-in XSLT from mid-December
• Chrome 155 update fixes ten security bugs, one rated critical

Sources

• Chrome for Developers: Removing XSLT for a more secure browser, 29 October 2025
• Chrome Platform Status: Deprecate and remove XSLT, 18 October 2026
• Chromium Dash: milestone schedule for Chrome 158 and 176 (read 2026-10-18), 18 October 2026
• Chrome Enterprise policy list: XSLTEnabled, 18 October 2026