Anup Karanjkar

Posted on Oct 18 Originally published at wowhow.cloud

Chrome 158 Drops XSLT on 17 November: Fix RSS and Sitemaps

#chrome158 #xsltremoved #rssfeed #xsltprocessordepreca

On 17 November 2026, Chrome 158 stops running XSLT on Stable for everyone except Origin Trial and Enterprise Policy participants, so any RSS feed, Atom feed or XML sitemap that relies on an XSL stylesheet will lose its styled browser view.[1] The XML itself still parses and still downloads. Feed readers and search engine crawlers read the data, not the stylesheet, so the damage is mostly to the page a human sees when they click your feed link. This post covers exactly which features are removed, which stay, a table of what breaks, and four fixes with code you can paste today.

TL;DR

Removed in Chrome 158 (17 Nov 2026): the XSLTProcessor JavaScript class and the <?xml-stylesheet type="text/xsl" ...?> processing instruction.[1]
Not removed: XML itself, and the text/css stylesheet processing instruction.[1]
Escape hatches are temporary: the Origin Trial starts in Chrome 152 (25 Aug 2026), and both the trial and the XSLTEnabled enterprise policy end in Chrome 176 (17 Aug 2027).[1]
Fastest fix for a feed or sitemap: swap the XSL line for a CSS line, or drop the line and point to an HTML page with a link rel="alternate" tag.
Check your own feed with the XSLT removal checker before the date.

What exactly Chrome is removing, and when

Chrome's own deprecation page, written by Mason Freed and Dominik Röttsches, says: "We intend to remove support from version 158 (November 17, 2026)."[1] Two things go away. One is the XSLTProcessor class you call from JavaScript. The other is the XSLT processing instruction, the <?xml-stylesheet type="text/xsl" href="..."?> line at the top of an XML file that tells the browser to transform the document into HTML before showing it.

The page is explicit that "we won't be removing XML from the browser; only XSLT is being considered for removal."[1] Chrome is also planning to move XML parsing off libxml2 onto a Rust-based parser, which is a separate change.

The timeline, from the Chrome page

Chrome version	Date	What happens

| 142 | 28 Oct 2025 | Early warning console messages |

| 143 | 2 Dec 2025 | Official deprecation, warnings in console and Lighthouse |

| 145 | 2 Dec 2025 (Canary) | Canary, Dev and Beta start disabling XSLT by default |

| 146 | 10 Mar 2026 | Enterprise Policy available for testing |

| 152 | 25 Aug 2026 | Origin Trial available |

| 154 | 22 Sep 2026 | WebView Canary, Dev and Beta start disabling XSLT by default |

| 158 | 17 Nov 2026 | XSLT stops working on Stable except for Origin Trial and Enterprise Policy participants |

| 176 | 17 Aug 2027 | Origin Trial and Enterprise Policy stop working; XSLT is off for everyone |

Read the last row twice. The Origin Trial and the policy buy you roughly nine months, not a permanent exemption.[1] If you are planning to enrol and forget about it, you are only moving the deadline to August 2027.

Why Chrome is doing it

The stated reasons are security and low usage. XSLT 1.0 dates to 1999, and the Chrome page says all major browser engines only natively support that original version, not 2.0 or 3.0. It points to CVE-2025-7425 and CVE-2022-22834 in libxslt as examples of the attack surface, and says only about 0.02% of page loads use XSLT at all, with under 0.001% using the processing instruction.[1]

The WHATWG HTML issue where the removal was proposed (issue 11523, opened 1 August 2025) is at "stage: 3 Committed" and still open as of my read on 18 October 2026.[2] Even a 0.001% share is a lot of sites at web scale, and the thread shows the feed-viewing use case came up repeatedly. That is why the fix list below starts with feeds.

What about Firefox, Safari and Edge?

Chrome's page says Firefox and WebKit have also indicated plans to remove XSLT, but neither has shipped a removal date that I could find.[1] What is on the public record:

Mozilla: its standards-positions issue 1287 was labelled "position: positive" on 27 August 2025, with the statement "Our position is that it would be good for the long-term health of the web platform." Mozilla also supports Chromium testing whether removal is web-compatible.[3]
WebKit: in the WHATWG thread, a commenter wrote on 4 August 2025 that "WebKit is cautiously supportive" and that they would "probably wait for one implementation to fully remove support."[2] That is a statement in an issue thread, not a ship date.
Microsoft Edge: it is Chromium-based, so expect it to follow Chrome's timing. I did not find a separate Edge announcement, so treat that as an inference.

Practical read: do not assume Safari or Firefox will keep your styled feed alive past 2027. Plan for no browser running XSLT.

Who actually breaks

Before the table, one distinction matters. There are two different consumers of your XML.

Machines (feed readers, podcast apps, search engine crawlers) fetch the XML and parse the elements. They have no reason to execute the stylesheet, which exists only to make the file look nice in a browser. So your feed data and your sitemap data keep working. I have not seen Google publish a statement about Chrome 158 and sitemaps, so this is reasoning from how these formats work rather than a quote. The sitemap protocol defines the XML, and the stylesheet is an optional layer on top of it.

Humans are the group who break. Someone clicks your "RSS" link, and today they see a tidy page. After 17 November they see either raw XML or an "XML tree" view, and many will think the feed is broken. That costs you subscribers, not rankings.

Affected thing	What breaks in Chrome 158	What keeps working	Fix

| Pretty-printed RSS or Atom feed with an XSL line | Browser shows raw XML or a tree, not the styled page | Feed readers, podcast apps, the data itself | CSS line, or alternate link plus HTML page |

| XML sitemap with an XSL viewer (many SEO plugins add one) | Human-readable table of URLs disappears | Crawlers reading the URL list; Search Console submission | Check your plugin; or drop the XSL line |

A note on SEO plugins and WordPress

Several SEO plugins and WordPress itself ship an XSL file for their sitemap pages. I could not find a published statement from Yoast or Rank Math on Chrome 158 in their docs or changelogs, so I will not guess what they will do: check your plugin's changelog and update before 17 November. A search result I saw points to WordPress core Trac ticket 65635 proposing an alternative to the XSLT stylesheet for XML sitemaps, but that page returned a 403 when I tried to open it, so I cannot describe its contents.

Fix 1: swap the XSL line for a CSS line

The Chrome page confirms the text/css processing instruction stays supported.[1] This is the least work for a simple feed. Replace the XSL line:



    My Blog

      First post
      https://example.com/first
      Short summary

And a minimal stylesheet. XML elements have no default layout, so you must set display yourself:

rss, channel, item { display: block; }
channel { max-width: 40rem; margin: 2rem auto; font: 16px/1.5 system-ui, sans-serif; }
channel > title { display: block; font-size: 1.8rem; font-weight: 700; margin-bottom: 1rem; }
item { border-top: 1px solid #ddd; padding: 1rem 0; }
item > title { display: block; font-weight: 600; }
link, description { display: block; color: #444; }
pubDate, guid, language, generator { display: none; }

The catch: CSS can style text but cannot turn a URL in a <link> element into a clickable anchor, and it cannot build a table from repeated nodes the way XSLT did. You get a readable page, not an interactive one. For a feed that is usually enough. For a sitemap with thousands of rows, it gives you a plain list.

Fix 2: drop the stylesheet and add an HTML landing page

The Chrome page's recommendation for feeds is to add a <link rel="alternate" type="application/rss+xml"> to your HTML site.[1] Put the real, human-facing explanation on an HTML page ("what is RSS, copy this URL into your reader") and let the XML be plain XML. In the head of your homepage:

Then link visibly to a /subscribe page from your footer instead of linking straight to the XML. This is also the better experience: a new visitor who has never heard of RSS gets instructions, not angle brackets. If you want to check how that page will look when shared, run it through the meta tags previewer.

Fix 3: do the transform on the server or at build time

If you like your XSL and want to keep it, run it before the browser sees anything. The Chrome page lists "run the XSLT pipeline on the server and send rendered HTML" as an option.[1] The command line tool xsltproc (part of libxslt, preinstalled on macOS and available in most Linux package managers) does it in one line. I ran this against a small test feed in this session and it produced the expected HTML list:

xsltproc feed.xsl feed.xml > feed.html

Serve feed.html as the human page and keep feed.xml as the machine feed, with no stylesheet line in the XML. In a Node build step, the npm package saxon-js (SaxonJS, an XSLT 3.0 processor for Node.js from Saxonica) works, usually after compiling the stylesheet to its SEF format with the companion CLI package xslt3. In Python, lxml from PyPI exposes lxml.etree.XSLT. Note that libxslt-based tools implement XSLT 1.0, while SaxonJS implements 3.0, so stylesheets written for one may need edits for the other.

Fix 4: keep XSLT in the browser with a library or polyfill

The Chrome page names three ways to keep client-side XSLT:[1]

Saxonica's client-side library (SaxonJS), which supports XSLT 3.0.
A WebAssembly-based polyfill, xslt-polyfill.min.js, that replaces XSLTProcessor so existing code keeps working. A single script line added to an XML file can transform it automatically.
An "XSLT polyfill" Chrome extension for raw XML pages, which the page suggests for devices you cannot update.

The page tells you to find the polyfill through a GitHub search rather than endorsing a specific repository. An npm package named xslt-polyfill exists (version 1.0.31 when I checked, described as a polyfill for browser-based XSLTProcessor), but I have not audited it, and I am not claiming it is the one the Chrome page means. Read the source and pin the version before shipping it to production. For an RSS feed, the Chrome page says the polyfill line "shouldn't affect RSS reader's ability to continue parsing the XML."[1]

How to test before 17 November

Chrome's page says Canary, Dev and Beta have disabled XSLT by default since Chrome 145, as an early warning. It does not list a specific flag or a step-by-step test procedure.[1] So the simplest test is to open your feed and sitemap URLs in a current Canary, Dev or Beta build and see whether you get a styled page or raw XML. Chrome has also been printing deprecation messages in the DevTools console since Chrome 142.

To find XSLT use on pages you do not control, the Chrome page gives a Reporting API approach: watch deprecation reports and look for the XSLT id. This is my own minimal version of that idea:

new ReportingObserver((reports) => {
  for (const r of reports) {
    if (r.body && r.body.id === 'XSLT') console.warn('XSLT used:', r.url);
  }
}, { types: ['deprecation'], buffered: true }).observe();

Enterprise admins can also turn on the Enterprise Legacy Technology Report in the Chrome admin console to see which internal sites still use it.[1] If your feed config lives in YAML, the YAML to JSON converter is handy for sanity-checking it, and the XSLT removal checker lets you paste a feed and see whether it carries an XSL line.

A 30-minute checklist

Open your feed URL and your sitemap URLs. View source and look for xml-stylesheet.
If the type is text/xsl, text/xml or application/xml, pick a fix above: Chromium runs all three (and the XHTML, RSS and Atom XML types) as XSLT stylesheets. If it is text/css, you are done. Not sure? Paste the file into the XSLT Removal Checker.
Search your JavaScript for XSLTProcessor, including vendored libraries.
Check your SEO plugin and CMS changelogs for a sitemap viewer update.
Add a link rel="alternate" tag to your HTML head if you serve a feed.
Re-test in Canary or Beta, then again in Stable after 17 November.

For the broader formatting side of this work, the JSON formatter and validator guide covers the JSON route the Chrome page recommends for XML endpoints you control, and the XML formatter is useful when you are tidying a feed by hand.

Frequently asked questions

Will my RSS feed stop working in feed readers?

No. Feed readers parse the XML elements and do not run your stylesheet. Only the browser view changes. The Chrome page says the polyfill approach should not affect a reader's ability to parse the XML.[1]

Will Google stop reading my XML sitemap?

Nothing I found says so. The change is to how Chrome displays XML, not to how crawlers fetch and parse it, and the sitemap URL list is plain XML. I have not seen Google state this for Chrome 158 specifically, so confirm in Search Console after the date that your sitemap still shows as read successfully.

Can I just enrol in the Origin Trial?

You can from Chrome 152, and it keeps XSLT working past 17 November 2026 for the enrolled origin. But the Origin Trial ends in Chrome 176 (17 August 2027), so it is a deadline extension.[1] Visitors also need a Chrome version that supports the trial, which is another reason to migrate.

Does the CSS stylesheet line really survive?

Yes. Chrome's page says the text/css processing instruction is not being removed.[1]

Is the removal final?

Chrome says it intends to remove from version 158. The WHATWG issue is at "stage: 3 Committed" and was still open on 18 October 2026.[2] Plan as if it ships on the date.

Sources

3. Mozilla standards-positions issue 1287: Removing XSLT (read 18 October 2026)

Originally published at wowhow.cloud

DEV Community