Chrome 158 stops running XSLT on November 17, 2026, the date scheduled at the time this article was published: if your website converts XML into a page inside the browser (a styled RSS feed, a sitemap that looks like a page, an internal app built on XSLTProcessor), it will stop working in Chrome. Here’s how to check it in five minutes and the three solutions, ordered by how much time each one gives you.
What is XSLT?
XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other formats, usually HTML. It works with two files: the XML with the data and an XSL stylesheet (.xsl) with the conversion rules. Browsers incorporated it in the early 2000s, but all of them stopped at XSLT 1.0, from 1999. The language kept evolving outside, with XSLT 2.0 in 2007 and XSLT 3.0 in 2017, and never came back to the browser.
What exactly does Chrome 158 remove?
The two ways the browser has to run XSLT disappear: the processing instruction that tells the browser to transform an XML when opening it (<?xml-stylesheet type="text/xsl" href="...">) and the JavaScript API XSLTProcessor.
The timeline, according to Chrome’s deprecation document:
| Chrome | Date | What happens |
|---|---|---|
| 143 | December 2, 2025 | Official deprecation; console warnings and Lighthouse alerts |
| 146 | March 10, 2026 | Enterprise Policy available |
| 152 | August 25, 2026 | Origin Trial available |
| 158 | November 17, 2026 | XSLT stops working in Stable, except with Origin Trial or Enterprise Policy |
| 176 | August 17, 2027 | Origin Trial and Enterprise Policy stop working; XSLT disabled for everyone |
Google’s argument is security: browsers only implemented XSLT 1.0 on top of aging XML parsing code and, according to Google’s own measurement, barely around 0.02 percent of page loads use XSLT. It’s not a Chrome-only decision either: the document indicates that Firefox and WebKit also support removing XSLT from the web platform, and Microsoft already documents the same temporary policy for Edge.
One detail worth knowing: Chrome 158’s release notes don’t mention the removal. At the time of publishing, the deprecation document is the only official place where it’s written.
Does this affect me if my website uses XSLT?
It affects you if the browser is the one running the transformation:
- You serve XML files (feeds, sitemaps, reports, catalogs) with an
<?xml-stylesheet type="text/xsl"?>line so they look like a styled page when opened in Chrome. - Your front-end code calls
new XSLTProcessor().
It doesn’t affect XSLT running on your server: Java, .NET, PHP’s XSL extension, libxslt in a build step. It also doesn’t affect programs that read your XML without showing it in Chrome, like feed readers and crawlers: they never used Chrome’s XSLT engine.
How do I know if my website uses XSLT?
1. Search your code. From your project root:
grep -rn "xml-stylesheet\|XSLTProcessor" .
2. Listen to deprecation reports. Chrome’s document shows how to detect XSLT usage with the Reporting API:
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
console.warn("XSLT in use:", report.body);
}
});
}, {types: ["deprecation"], buffered: true}).observe();
Send that to your logging system instead of the console and you’ll have an inventory with real traffic.
3. Test the future today. Disable XSLT at chrome://flags/#xslt and load your pages. Whatever breaks there is what breaks on November 17.
4. If you manage a fleet of browsers, Chrome Enterprise’s Legacy Technology Report shows which internal sites still use XSLT.
How does the XSLT Origin Trial work and how long does it last?
The Origin Trial lets your public website keep using native XSLT after the removal. You register your origin on Chrome’s origin trials console, get a token, and serve it one of these two ways:
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
Origin-Trial: TOKEN_GOES_HERE
The token only works for the origin you registered. If you serve XML files directly with a processing instruction, they don’t have an HTML <head>, so use the HTTP header instead.
The limit: it ends with Chrome 176, on August 17, 2027. That’s about nine months after the removal date: time to migrate, not a permanent solution.
How do I keep XSLT with the XSLTEnabled enterprise policy?
If XSLT lives in internal applications and your company manages its browsers, the XSLTEnabled policy keeps XSLT available on those devices. It’s available starting with Chrome 146. Enable it from your admin console or with Group Policy and verify it was applied at chrome://policy.
For Edge, Microsoft documents the same policy (Edge 147 and later) and marks it as temporary:
- Registry:
SOFTWARE\Policies\Microsoft\Edge - Value:
XSLTEnabled, typeREG_DWORD,0x00000001 - macOS: key
XSLTEnabled, value<true/>
The limit: it only covers the browsers you manage (your public visitors don’t have it) and in Chrome it also stops working in version 176.
Is there an XSLT polyfill for Chrome?
Yes, and it covers most of XSLT 1.0. The polyfill that Chrome’s document points to, xslt_polyfill (npm package xslt-polyfill, BSD-3-Clause license), runs libxslt and libxml2 compiled to WebAssembly and reimplements the complete XSLTProcessor API. It doesn’t depend on any trial, so it has no expiration date.
For JavaScript code that already uses XSLTProcessor, load the script first and leave your code as is:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
For an XML file with a processing instruction, add a line as a direct child of the root element:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
xmlns="http://www.w3.org/1999/xhtml"></script>
...content...
The script detects the processing instruction, runs the transformation, and replaces the document. According to Chrome’s guide, that line shouldn’t affect RSS readers.
How do I view an XML with XSLT in Chrome after November 17?
There’s a Chrome extension that applies the same polyfill to all XML pages that use XSLT. It’s useful for users of an application you can’t modify: they install the extension and the XML still looks the same.
What are the polyfill’s limitations?
Its own README details them honestly:
- Only XSLT 1.0. If you need 2.0 or 3.0, this isn’t the tool.
- Same origin only. URLs from another origin and
data:URLs are blocked even with CORS headers. xsl:include,xsl:import, anddocument()are downloaded asynchronously, soXSLTProcessor’s synchronous methods fail when a stylesheet uses them.- The file must be served as UTF-8, because the WebAssembly is embedded in the script.
- Native XSLT runs first. As long as your Chrome still has XSLT, the polyfill never kicks in: test with
chrome://flags/#xsltdisabled or you won’t be testing anything.
The author describes it as a temporary solution and recommends SaxonJS for real XSLT support.
How do I convert XML to HTML without XSLT in the browser?
The permanent solution is to move the transformation out of the browser. Chrome’s document proposes three paths:
- Transform on the server and send finished HTML. If you already have the
.xsl, any server-side XSLT engine can run it. - Change the endpoint to JSON and render it with JavaScript.
- Use SaxonJS if you need XSLT on the client: it’s the largest XSLT library in JavaScript and supports XSLT 3.0.
For RSS and Atom on an HTML site, the recommendation is to stop linking the XML visibly and declare it in the <head>, which is where feed readers look for it:
<link rel="alternate" type="application/rss+xml">
Which option should I choose?
| Situation | Option | Lasts until |
|---|---|---|
| Public site that won’t migrate before the 17th | Origin Trial | August 17, 2027 |
| Internal app on managed browsers | Enterprise Policy | August 17, 2027 (Chrome) |
| XSLT 1.0, same origin, no time to rewrite | Polyfill | No fixed date; temporary |
| Anything you plan to keep | Server, JSON, or SaxonJS | Permanent |
A reasonable order: check this week, use the trial or policy if you need margin, and dedicate those nine months to moving the transformation to somewhere that doesn’t depend on the browser.
What about you? Where do you still have XSLT: in a feed, in a sitemap, or in an internal app?
- I’m moving it to the server or to JSON
- Polyfill while I migrate
- Origin Trial or enterprise policy
- I prefer another option (tell us which)
Comment below or, if this article reached you by email, reply directly to the email: your reply gets published here.
yoDEV Tested