Chrome Removes XSLT: Your Styled Feed Goes Blank
Quick answer: Chrome 158 stops processing XSLT on 17 November 2026. Any <?xml-stylesheet type="text/xsl" ?> on your feed or sitemap stops rendering, and visitors get a wall of raw XML instead of a styled page. Search engines never read that stylesheet, so nothing about your indexing changes — which is exactly why this will reach you as a bug report rather than as a metric.
There is a line in most developer blogs' feed.xml that nobody has touched since the day it was written. It points at an XSL stylesheet whose only job is to turn the raw feed into something a human can read when they click the RSS link. Chrome is about to stop executing it.
Google published the removal plan on Chrome for Developers, and it is not a proposal. The dates are fixed, the deprecation warnings have been in the console since late 2025, and the escape hatches expire in 2027.
What is actually being removed
Two things, and it is worth being precise because the third thing that looks similar survives.
The first is the XSLTProcessor class — the JavaScript API you would call as new XSLTProcessor() to transform an XML document in the page. The second is the XSLT processing instruction itself, <?xml-stylesheet type="text/xsl" ?>, which is the one sitting in your feed.
What does not go away is the CSS variant, <?xml-stylesheet type="text/css" ?>. If all you want is for an XML document to not look like a stack trace, a plain CSS stylesheet still works and is the cheapest migration available to you. It cannot restructure the document, but it can make the existing structure legible.
The timeline, in the order it affects you
| Milestone | What happens |
|---|---|
| Chrome 143 | Formal deprecation; warnings in console and Lighthouse |
| Chrome 146 (10 Mar 2026) | Enterprise Policy available for testing |
| Chrome 152 (25 Aug 2026) | Origin Trial opens |
| Chrome 154 (22 Sep 2026) | WebView Canary, Dev and Beta disable XSLT |
| Chrome 158 (17 Nov 2026) | XSLT stops working on Stable |
| Chrome 176 (17 Aug 2027) | Origin Trial and Enterprise Policy expire; full removal |
Read the last row carefully. The Origin Trial is not a reprieve, it is a nine-month extension with a hard stop. If you enrol in it you have bought time to do the migration, not permission to skip it.
Why this lands on feeds and sitemaps first
XSLT survived on the web in exactly two places: enterprise XML pipelines, and the pretty-printing of machine-readable files that humans occasionally click. The second category is where most developer sites are exposed.
Feed generators have shipped XSL stylesheets for years because a raw RSS document is hostile to anyone who clicks the orange icon by accident. The same pattern spread to sitemap.xml: several sitemap plugins and static-site generators attach a stylesheet so the file renders as a table instead of a tag soup. The processing instruction is identical in both cases, so the same removal applies to both — Chrome's document is about the API and the instruction, not about any particular file name.
If you generate either file from a template you control, this is a five-minute audit. If you generate them from a plugin, the fix is waiting on whoever maintains that plugin. Worth checking now rather than in November. If you are rebuilding a sitemap from scratch anyway, our sitemap XML generator emits a plain file with no stylesheet attached, which is one fewer thing to revisit.
Nothing about your search visibility changes
This is the part that gets misreported, so let us be blunt about the mechanism. A crawler fetching sitemap.xml parses the XML. It reads <loc> elements. It does not run a browser, it does not resolve the stylesheet, and it does not care what the file would have looked like to a person. The stylesheet is a cosmetic layer for human visitors and always was.
So the damage here is entirely reputational and entirely human: a developer clicks your RSS link, sees raw XML, and quietly concludes the site is unmaintained. That is a real cost for a tools site or a directory, but it is not a ranking event. Treat it the same way you would treat a broken favicon — low severity, high embarrassment. If you want the machine-readable side of your site audited properly, that is a separate exercise from this one, and our robots.txt generator and meta tag generator cover more of it than a stylesheet ever did.
Your three options, ranked
1. Delete the stylesheet and stop linking the raw file
Chrome's own guidance for feeds is to stop surfacing the XML to users at all: advertise the feed with <link rel="alternate" type="application/rss+xml"> in your HTML head, which is what feed readers actually look for, and let the visible link on the page point at a normal HTML page. This is the correct answer for almost every site. The XML file remains; it just stops being a destination.
2. Add the WebAssembly polyfill
Chrome's documentation points at a WebAssembly-based polyfill that restores XSLTProcessor, and for feeds the suggested integration is a single script line added to the XML itself. It works, but weigh what you are doing: shipping a WebAssembly runtime so that a file nobody was supposed to look at renders nicely. For a documentation site with a genuine XSLT-driven view, fine. For an RSS feed, it is a lot of machinery for a cosmetic outcome.
3. Move the transform off the client
If the XSLT is doing real work — a genuine XML pipeline, not decoration — run it at build time or on the server and serve HTML. Saxonica's JavaScript implementation supports XSLT 3.0 and is the most complete option if you need to keep the stylesheets themselves. Otherwise, the migration Chrome recommends is the boring one: move the data to JSON and render it with the framework you already use.
Do not plan around Firefox or Safari saving you
The removal came out of a WHATWG discussion, not a unilateral Chrome decision. Per LWN's account of the debate, Mozilla was supportive of removal and argued for console warnings sooner rather than later, and Apple's WebKit team was described as cautiously supportive while likely waiting for one implementation to remove it first.
That is a specific position worth reading correctly: as of today Chrome is the only engine with a published removal date, and neither Mozilla nor Apple has shipped a removal. But "the other two are waiting to see" is not the same as "the other two will keep it." Build for a web without client-side XSLT.
The pushback was loud, including the argument that removal amounts to signing a death warrant for RSS feeds. It is an overstatement — feed readers parse XML and never touched the stylesheet — but it points at the real loss, which is that the one human-friendly on-ramp to a feed disappears.
The ten-minute audit
Grep your build output for xml-stylesheet and for XSLTProcessor. Check feed.xml, rss.xml, atom.xml, every sitemap*.xml, and any admin or reporting view that renders XML. Then open the ones you find in a current Chrome with the console open; the deprecation warning tells you directly.
This is the kind of maintenance that gets skipped because nothing is on fire, which is precisely why it is worth doing in a quiet week. The same instinct applies to the rest of your machine-readable surface — we made the same argument about llms.txt and about structured data after FAQ rich results: the files nobody looks at are the ones that rot. If you want more of this kind of upkeep tooling in one place, the full set lives at TechLogHub Tools, and the platform side sits under developer tools.
FAQ
Will my RSS feed stop working in feed readers?
No. Feed readers parse the XML directly and have never executed the XSL stylesheet. Only the in-browser rendering of the raw file changes.
Does this affect how Google crawls my sitemap?
No. Crawlers parse the XML elements and ignore the presentation stylesheet entirely. Your indexing is unaffected either way.
What exactly happens on 17 November 2026?
Chrome 158 reaches Stable with XSLT disabled. Documents with an XSL processing instruction render as unstyled XML, and calls to XSLTProcessor fail. Sites enrolled in the Origin Trial or covered by the Enterprise Policy keep working until Chrome 176 on 17 August 2027.
Can I keep a styled feed without XSLT?
Yes, two ways. Attach a CSS stylesheet with the text/css variant of the processing instruction, which is not being removed, or stop linking the XML publicly and point readers at an HTML page that lists the same posts.
Are Firefox and Safari removing XSLT too?
Neither has shipped a removal or published a date. In the WHATWG discussion Mozilla was supportive of removing it and Apple's WebKit team was described as cautiously supportive, likely waiting for another engine to go first. Assume the direction of travel is one way.
Is the Origin Trial worth enrolling in?
Only if you have a real XSLT-driven application that cannot be migrated by November. For a decorative feed stylesheet, deleting the line is faster than enrolling.
A quarter century of XSLT in the browser, and the thing it will be remembered for is making RSS look nice.