Alan West

Posted on Oct 18 Originally published at blog.authon.dev

Chrome 158 Removes XSLT on Nov 17. Here's What Breaks and How to Fix It

#javascript #html #rss #webdev

On November 17, 2026, Chrome 158 turns off XSLT for everyone on Stable. That's 30 days from when I'm writing this, and Edge 159 follows in mid-December. If your RSS feed shows a styled page when someone clicks it, or your sitemap.xml renders as a tidy table instead of a wall of tags, that page is probably about to turn into raw XML or an error. Same for any JavaScript that calls new XSLTProcessor().

Microsoft's own RD Web Access portal is on the list of things that break. Microsoft says so in a support article, and it has no fix yet.

The Chrome and Edge XSLT removal timeline

From Google's deprecation page:

Chrome version	Date	What happens
143	Dec 2, 2025	Official deprecation, warnings in console and Lighthouse
146	Mar 10, 2026	`XSLTEnabled` enterprise policy available
152	Aug 25, 2026	Origin Trial available
158	Nov 17, 2026	XSLT stops working on Stable, except OT and policy users
176	Aug 17, 2027	Origin Trial and policy stop working. Gone for everyone

Edge's notice MC1509789 (published Oct 15, 2026) says browser-native XSLT is off by default in Edge 159 Stable, rolling out from mid-December 2026, and the XSLTEnabled policy goes away in Edge 176 in summer 2027.

Don't count on Firefox to bail you out. Mozilla posted an Intent to Unship on August 26, 2026, with the plan to disable it in all channels in August 2027, lined up with Chromium. WebKit engineers gave the removal positive feedback too. As Eric Meyer pointed out back when this started, this wasn't Google acting alone.

What breaks when XSLT is gone (and what doesn't)

Only two things are being removed: the <?xml-stylesheet type="text/xsl" ...?> processing instruction in XML documents, and the XSLTProcessor JavaScript API.

Thing	After Chrome 158
RSS/Atom feed with an XSL stylesheet, opened in a browser	Breaks: raw XML or an error
`sitemap.xml` with an XSL "pretty view" (common with SEO plugins and WordPress core's `wp-sitemap.xsl`)	Breaks for humans
JS calling `new XSLTProcessor()`	Breaks
Legacy intranet apps, device admin UIs, IIS reports in XML+XSL	Break
Feed readers parsing your RSS	Fine
Googlebot and other crawlers reading your sitemap	Fine
XSLT on the server (PHP `XSLTProcessor`, `xsltproc`, Saxon, Java)	Fine, it never touched the browser
XML with `<?xml-stylesheet type="text/css"?>`	Fine, Microsoft says so explicitly

The sitemap one is where people panic for no reason. Joost de Valk wrote it plainly: "Only the XSLT view that makes it look pretty is going away." Search engines never cared about your stylesheet, so your SEO is fine. The only person who loses anything is whoever clicks your sitemap link to "check it", and they get a less pretty page.

The intranet case is the one that hurts. Nobody's going to patch the 2011-era internal tool that renders XML reports client-side before November, and the router admin page and the government portal are in the same spot.

Check if your site uses XSLT in 2 minutes

Look for an XSL processing instruction in anything you serve as XML:

curl -s https://yoursite.com/feed.xml | grep -o '<?xml-stylesheet[^>]*>'
curl -s https://yoursite.com/sitemap.xml | grep -o '<?xml-stylesheet[^>]*>'

If the output contains type="text/xsl" (or an href ending in .xsl), you're affected. type="text/css" means you're not.

Then search your repo for both triggers:

grep -rn -e 'xml-stylesheet' -e 'XSLTProcessor' --include='*.xml' --include='*.xsl' \
  --include='*.js' --include='*.ts' --include='*.php' --include='*.html' .

To see what your users will see, disable it in your own browser at chrome://flags/#xslt (the polyfill README points there) and reload the page. Since Chrome 143 the DevTools console also shows a deprecation warning on affected pages, so if you've been ignoring yellow text in there, go read it.

If you manage a fleet of machines, have someone set the XSLTEnabled policy to disabled on a test group now. Google's deprecation page suggests the policy for exactly that: testing the removal early.

Fix 1: Run the XSLT at build time with xsltproc

This is the cleanest fix. If your XSL turns feed.xml into a readable page, run the transform once and ship the HTML:

xsltproc -o feed.html feed.xsl feed.xml

xsltproc ships with libxslt, the same library Chrome is pulling out. Put it in your build step or CI, link to feed.html for humans, and keep feed.xml for machines. For XSLT 2.0/3.0 stylesheets, Saxon does the same job.

Static site generators make this easier still. Most already have the data as front matter, so you can skip XSLT and render an HTML archive page from the same list of posts. Joost's advice for sitemaps is the same: generate the XML and an HTML page from one source.

Fix 2: Drop in the xslt-polyfill script

Google's Mason Freed maintains xslt-polyfill, which is libxslt and libxml2 compiled to WebAssembly. It's on npm as xslt-polyfill. For an XML file with an XSL processing instruction, you add one line inside the document:

<script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>

It finds the <?xml-stylesheet?>, fetches the XSL, runs the transform, and replaces the document. For code that uses XSLTProcessor, include the script normally and your existing importStylesheet() / transformToFragment() calls keep working. Set window.xsltUsePolyfillOnlyIfNeeded = true before it loads to skip it in browsers that still have native support.

The Chromium intent to deprecate and remove post has numbers on how well it works. The author reports that about 75% of sites hitting the XSLT use counter didn't look visibly broken, and that adding the polyfill restored functionality on 82% of the rest. So nearly one in five of the genuinely broken sites can't be saved this way, mostly because of CORS. The README lists the catches:

Imported or included stylesheets are fetched with fetch(), so CORS applies, and the synchronous XSLTProcessor methods fail in that case.
The file must be UTF-8 or the embedded Wasm decodes wrong.
Pages without a DOCTYPE render in standards mode instead of quirks mode.
Scripts in the output get re-created so they run, and the load event you see is a synthetic one fired after they're inserted.

For pages you can't edit at all (that vendor appliance), there's a Chrome extension that applies the same polyfill.

Fix 3: Give humans an HTML page and leave the XML to machines

Stop making the XML file the thing humans click. Put the feed in your <head>:

<link rel="alternate" type="application/rss+xml" title="My Blog" href="/feed.xml">

Then make the visible "Subscribe" link go to an HTML page that explains RSS and shows the feed URL to copy. Readers and browser extensions find the feed through the <link>. Same for sitemaps: a real /sitemap HTML page for people, sitemap.xml for crawlers.

If you want something visual on the raw XML, swap the XSL for a CSS stylesheet with <?xml-stylesheet type="text/css" href="feed.css"?>, which stays supported. CSS can only restyle elements you already have, though. It can't reorder them, loop over them or turn <link> text into clickable anchors, so it's a cosmetic patch at best.

Enterprise stopgap: the XSLTEnabled policy

If an internal app can't be fixed by November, the XSLTEnabled policy buys you until version 176. From Microsoft's RD Web Access article:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v XSLTEnabled /t REG_DWORD /d 1 /f

That gets you roughly nine more months, so put the migration on someone's calendar now.

My take: the right call, done lazily

I'll give Google the security argument. libxslt is an aging C codebase with a CVE history (the deprecation page cites CVE-2025-7425 and CVE-2022-22834), it gets far less maintenance and security review than a JS engine, and Chrome measured XSLT on about 0.02% of page loads. Nobody wants to keep a memory-unsafe parser alive in every browser for that.

What bugs me is that the fix already exists. The polyfill is the same libxslt sandboxed in Wasm, where a memory bug stays inside the sandbox, and browsers could have shipped that internally and kept every old page working. A few people in the Hacker News thread made a similar point. Instead, "don't break the web" now means "the web is fine as long as each site owner adds a script tag." The owners of abandoned government portals and 15-year-old device UIs won't bother, so those pages just die. And 0.02% of page loads sounds tiny until you notice it's mostly the stuff nobody is around to fix anymore.

So: is anything you maintain still running XSLT in the browser? Or is this the right call, and I'm just mourning a standard nobody was going to update anyway?

DEV Community