Chrome Plans to Disable XSLT in Stable 158 on November 17 Outside Trial and Policy Exceptions; Edge Says 159; a Study Estimates About 120 Broken Pages

Overview

Chrome’s documentation dates Chrome 158 to November 17, 2026 and says that in that version, “XSLT stops functioning on Stable releases, for all users other than Origin Trial and Enterprise Policy participants.” That is according to the Chrome for Developers page, which was last updated on 2025-10-29. Chrome 158 has been in beta since October 28, 2026, the Chrome blog states. Microsoft’s Edge 157 stable release notes, dated November 5, 2026, set a separate schedule: browser-native XSLT is to be off by default in Edge’s Stable channel in Edge 159. A public compatibility study of the 2026-09-01 HTTP Archive crawl extrapolates its sample to about 120 broken pages.

Background: what is being removed, and why

Two interfaces are affected: the XSLTProcessor JavaScript class and the XSLT processing instruction in XML files, Chrome for Developers lists. The same page says Chrome is not removing XML, and that the <?xml-stylesheet?> instruction remains supported when used with CSS. Edge’s notes likewise say that processing instructions that reference CSS stylesheets are not affected.

Chrome’s stated reason is security. Its page says “the continued inclusion of XSLT 1.0 in web browsers presents a significant and unnecessary security risk,” describes the underlying libraries, such as libxslt, as “complex, aging C/C++ codebases,” and names CVE-2025-7425 and CVE-2022-22834, both in libxslt, as examples. It also says “about 0.02% of web page loads today actually use XSLT at all, with less than 0.001% using XSLT processing instructions” (Chrome for Developers). The MDN page for XSLTProcessor carries a deprecation banner saying XSLT “is a candidate for removal from browsers because browser implementations are highly susceptible to memory safety vulnerabilities.”

LWN.net, in an article dated August 27, 2025, reported that Chrome and Safari use libxslt while Firefox uses the TransforMiiX XSLT processor, and that browsers support only XSLT 1.0, finalized in November 1999. LWN also recounted earlier Google attempts: Adam Barth’s 2013 notice to the Blink development list and Dominic Cooney’s 2015 attempt.

Schedules and positions

Chrome’s page lays out a plan in which Canary, Dev and Beta releases disable XSLT by default from Chrome 145, an enterprise policy for testing arrives in Chrome 146 (March 10, 2026), an origin trial in Chrome 152 (August 25, 2026), and the removal in Stable in Chrome 158 (November 17, 2026). In Chrome 176 (August 17, 2027), the origin trial and enterprise policy “stop functioning,” and “XSLT is disabled for all users” (Chrome for Developers). The page also lists console-warning and deprecation steps in Chrome 142 and 143 and a WebView step in Chrome 154.

Edge’s notes say browser-native XSLT will be off by default in Canary, Dev and Beta in Edge 157 and in Stable in Edge 159. They add that Edge’s XSLTEnabled policy and the origin trial are temporary, and are “planned to stop functioning in Microsoft Edge 176” (Microsoft Learn).

Chrome’s page says the Firefox and WebKit projects “have also indicated plans to remove XSLT from their browser engines.” The statements of those projects are worded more cautiously. On Mozilla’s standards-positions tracker, an August 27, 2025 comment says: “Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium’s effort to find out if it would be web compatible to remove support.” The issue was closed with the labels “position: positive” and “concerns: compatibility.” That comment was posted by the GitHub user zcorpan, who also wrote the compatibility study described below. For WebKit, Anne van Kesteren wrote on August 4, 2025: “WebKit is cautiously supportive. We’d probably wait for one implementation to fully remove support”. None of the cited sources gives a date by which Firefox or Safari would disable XSLT in stable releases.

What the compatibility study found

The study’s author is Simon Pieters, whose GitHub profile lists Mozilla as his employer. According to the study’s README, the 2026-09-01 HTTP Archive crawl had 632 pages that applied an XSLT processing instruction (0.001% of desktop pages, 0.0015% of mobile) and 2,418 that constructed an XSLTProcessor (0.0057% desktop, 0.0042% mobile). It reports that no page did both. The author loaded a random sample of 200 of these pages in Chrome Canary 158 with XSLT on and off and reviewed them manually: 12 were broken, 85 worse, 68 showed no visible change and 35 could not be assessed. The README extrapolates this to about 120 broken pages and about 1,260 worse ones. These are the study’s figures and extrapolations, not the Herald’s; for the broken-page estimate the README gives per-counter 95% intervals of 15 to 121 (processing instructions) and 15 to 285 (XSLTProcessor).

The README describes the broken pages as ones whose XML is the human-facing document, such as a customer portal, a university phone directory and a parcel carrier login, plus a restaurant menu widget and some Flarum forums. The “worse” group is “mostly SEO sitemaps and RSS/Atom feeds, which show the raw XML viewer.” Of the 13 hits among the top 100,000 pages by CrUX rank bucket, it reports 10 with no visible change and 3 not assessable. In a GitHub comment dated October 19, 2026, the author wrote: “Things are slightly better than last year, but there’s still some breakage, mostly on small sites.” In the same comment he wrote that he “used Claude” to redo his earlier analysis.

The README states its own limits. The crawl “mostly doesn’t visit feeds, sitemaps, deep links, intranets, and logged-in pages.” It also notes that Chrome’s field rate for XSLTProcessor, 0.01% to 0.08% of page loads in October 2026 according to the README’s citation of Chrome’s status site, is “several times the crawl’s,” which “may mean the crawl undercounts” or that the API “is on a few heavily used pages.” Chrome’s own figure of about 0.02% of page loads is from a page last updated in 2025. The README adds that Microsoft says RD Web Access “stops rendering as expected without XSLT,” “presumably beyond the login page, which neither the crawl nor this check reaches.”

The polyfill follow-up

Mason Freed, an author of Chrome’s removal page, asked on October 27, 2026 whether the study could be rerun in a browser with an XSLT polyfill extension, so that pages still broken could be fixed in the polyfill. The README says the 239 pages from its earlier sections were loaded on 2026-10-31 in Chrome Canary 158 and Firefox Nightly 161.0a1, each with native XSLT off and an extension installed. A follow-up comment says 17 of the 24 pages rated broken render like native with the extension, apart from small layout differences. It lists others that stayed broken, among them Shift_JIS and Big5 documents that fail to transform and an iframe whose onload handler runs before the transform. It also lists pages rated worse that the extension does not fix, among them pages whose Content Security Policy blocks the Wasm module. On November 6, 2026 Freed replied that he had fixed the reported issues “modulo a few exceptions” and pushed a new extension version, and that in his testing it works on all the examples except olrb.gov.on.ca and legolas.md-medicus.net.

Chrome for Developers suggests moving XSLT processing to the server, serving JSON and rendering on the client, using a JavaScript XSLT library, the polyfill or an extension, and notes that Chrome shows a warning banner when XSLT is disabled. For feeds it recommends a <link rel="alternate" type="application/rss+xml"> in an HTML page, and concedes this does not solve the case of a user who pastes a feed link into a browser rather than a feed reader. Microsoft Learn advises Edge administrators to identify internal applications that use XSLT, test with it disabled, and migrate to server-side or JavaScript-based transformation, and says they can temporarily enable the XSLTEnabled policy.

The removal has opponents. In the August 2025 WHATWG discussion, LWN.net reported, Aram Zucker-Scharff said that removing visual rendering of RSS feeds would mean “signing a death warrant for RSS feeds as an open technology,” and Alberto Betella cited a podcasting use case. Tab Atkins Jr. said it should be “relatively trivial” to generate HTML from XML on the server. LWN also reported Freed’s reply to calls for improving XSLT rather than removing it: the Chrome team was “strongly convinced that this would not be the right way to spend our limited resources.” The thread was eventually locked to outside comments, LWN wrote.

What we don’t know

The cited sources do not say when Firefox or Safari will disable XSLT in stable releases. The compatibility study covers Chromium only for native behavior, and says feeds, sitemaps and logged-in pages are rarely visited by the crawl. Chrome’s 158 date comes from a page last updated in 2025, and the Chrome blog post for the beta does not restate it.

The study’s author said, in the comment quoted above, that he used Claude for his analysis. The Herald’s contributor model is built by Anthropic.