Contents
Chrome’s XSLT deprecation page schedules the end of XSLT on Stable for Chrome 158, dated November 17, 2026. Two things go: the XSLTProcessor JavaScript class, and the <?xml-stylesheet type="text/xsl" ...?> processing instruction. The first is easy to find in a code search. The second lives in XML files and templates that nobody has opened in years, and it fails in a way that no automated check will report.
Which half breaks quietly
An XML document with an XSLT stylesheet reference is transformed by the browser at load time. The server sends XML. Chrome fetches the stylesheet, applies it, and shows the result. That is why some sites ship a feed or sitemap that looks like a styled page in a browser.
Everything else that consumes those files reads the raw XML. Feed readers, search crawlers and curl never ran the stylesheet. So when Chrome stops doing it, the machine-facing behavior is identical, uptime checks stay green, and the only people who see a change are humans who open the URL in Chrome. For a feed, that is often the person deciding whether to subscribe.
The deprecation page says the same thing about feeds in its guidance: put a <link rel="alternate" type="application/rss+xml"> on the HTML site rather than linking visitors straight at the XML.
The dates that matter
From the same page, as I read it on October 18:
| Chrome | Date | What happens |
|---|---|---|
| 152 | Aug 25, 2026 | Origin Trial available |
| 158 | Nov 17, 2026 | XSLT stops working on Stable, except for Origin Trial and Enterprise Policy participants |
| 176 | Aug 17, 2027 | Origin Trial and Enterprise Policy stop working; disabled for everyone |
Two cautions. The page is dated October 29, 2025, and I found copies and summaries quoting different milestone numbers, so check the version and date against Chrome’s own platform status entry for your release plan instead of trusting a table in a blog post, including this one. And the page does not say what Chrome renders for an XML document whose stylesheet no longer runs. I did not test that, so I will not guess. Open one of your own feeds in a Chrome Beta build and look.
The processing instruction with CSS (type="text/css") is not affected, per the same page. That matters if your fix is to restyle the raw XML.
Where the pressure comes from
The deprecation page’s stated reason is security: XSLT 1.0 support in browsers depends on libxslt, which it describes as an aging C/C++ codebase that is “notoriously susceptible to memory safety vulnerabilities”. It also says only about 0.02% of page loads use XSLT. Those are Chrome’s numbers and I have not seen them independently measured.
It is not only Chrome. The original proposal in whatwg/html#11523 drew a WebKit statement of “cautiously supportive” with a preference to wait for one implementation to fully remove support. The Chrome page says Firefox and WebKit also plan to remove it. Treat the date for those engines as unknown. The thread I read names no Mozilla position beyond two individual commenters in favor.
A ten-minute audit
Search two places: the source you control, and the bytes you actually serve. The second catches stylesheets injected by a framework or plugin.
# source: stylesheets and JS use
find . \( -name '*.xsl' -o -name '*.xslt' \) -not -path './node_modules/*'
grep -rIlE 'XSLTProcessor|xml-stylesheet' . --exclude-dir=node_modules --exclude-dir=.git
# deployed: whatever your build or live server emits
curl -s https://example.com/feed.xml | head -5
curl -s https://example.com/sitemap.xml | head -5
Look for <?xml-stylesheet type="text/xsl" in the first lines of each XML response. Check every XML endpoint, not only the feed: sitemap indexes, per-tag feeds, podcast feeds, and any legacy report or SOAP-style endpoint someone viewed in a browser.
I ran the first check on this site. I built it with Hugo 0.163.3 and searched the output directory: 462 .xml files (the main RSS feed, per-section and per-tag feeds, and the sitemap), zero occurrences of xml-stylesheet, zero of XSLTProcessor. Hugo’s default feed and this site’s sitemap template emit the XML declaration and nothing else, so on this site the answer is that nothing breaks. That is also the common case for generated feeds. The risk is concentrated in sites that added a pretty-print stylesheet on purpose, or inherited one from a CMS plugin.
What to do with a hit
Chrome’s page lists the options: render HTML on the server, move the data to JSON and render client side, use Saxonica’s JavaScript XSLT 3.0 implementation, or load a WASM-based polyfill, which for raw XML pages is a one-line <script> per the page. I have not tried any of them. For a feed, the cheapest is usually to delete the processing instruction and add the HTML alternate link, since the stylesheet only ever served the human who landed on the XML by accident.
The Origin Trial and Enterprise Policy only buy time until August 17, 2027. If a hit sits in a system you cannot change before the 17th, decide now whether it is a deprecation you accept or a ticket you file.
Sources
- Removing XSLT for a more secure browser, Chrome for Developers, dated Oct 29, 2025. Timeline, scope of removal, CSS exception, replacement options, the security rationale and the 0.02% figure.
- whatwg/html#11523, opened Aug 1, 2025. The WebKit “cautiously supportive” statement and the individual Mozilla commenters.
- The build-output audit is my own run on this repository at Hugo 0.163.3.