Chrome stops running XSLT on November 17. Check your site in two minutes, then pick one of three fixes

What stops on November 17

XSLT is an old web feature that lets a browser take an XML file and turn it into a readable page using a stylesheet. You've probably seen it without knowing: the sitemap that opens as a neat table of links, the RSS feed that looks like a styled list of articles instead of a wall of tags, the internal reporting tool from 2011 that shows an XML export as a formatted report.

Chrome is removing it. From Chrome 158, which Google's schedule puts on November 17, 2026, XSLT stops working on Chrome Stable for everyone except organizations enrolled in an origin trial or running an enterprise policy that keeps it on. Those exceptions end with Chrome 176 on August 17, 2027. Google gives security as the reason, and the other browser engines are heading the same way: Chrome's page says Firefox and WebKit also plan removal.

Two specific things go. The line at the top of an XML file that says "style me with this XSL file," and the XSLTProcessor JavaScript API. XML itself keeps working, and so does styling XML with plain CSS.

Google measured XSLT on about 0.02% of page loads, so most sites won't notice. The point of the next two minutes is to find out whether yours is one that will.

Two minutes: find out if you're affected

Open your sitemap and your RSS feed in a browser and view the source. Look at the first few lines. If you see a line beginning <?xml-stylesheet with type="text/xsl" or an href ending in .xsl, that file uses XSLT. If it says text/css, it doesn't.

Then ask whoever looks after your code to search the codebase for two strings: xml-stylesheet and XSLTProcessor. The first finds styled XML files. The second finds JavaScript that transforms XML in the browser, which is the case that actually breaks features.

Finally, think about the tools nobody owns. The admin page on a warehouse printer, a supplier portal, an internal report someone built years ago that "just opens in Chrome." Developer Alan West's write-up suggests turning XSLT off in your own browser through Chrome's flags page to see what your users will see after the 17th. Since late 2025, Chrome has also printed a deprecation warning in the developer console on affected pages.

Whatever you find falls into one of three cases.

If it's your sitemap or your feed

This is the most common case and the least serious. The sitemap is for search engines, and they never looked at the pretty version. Joost de Valk, who founded the Yoast SEO plugin, put it simply in September: keep your sitemap, because only the styled view is going away. Feed readers keep reading your feed, too.

What changes is that a person who clicks the sitemap or feed link sees raw XML. Usually that's a developer, an SEO consultant or you, so the fix can be modest.

If a plugin or your CMS makes the sitemap, check whether its next update drops the stylesheet, and don't switch the sitemap off. If you build it yourself, remove the stylesheet line and keep the XML. If people genuinely use the readable version, a "Subscribe" page explaining your feed, or an HTML archive of your pages, give them a normal web page built from the same list.

If it's a feature in your web app

This is the case to take seriously. If your app calls XSLTProcessor, a feature stops working on November 17 for most Chrome users, with no error your customers will understand.

You have three ways out, in rough order of preference.

Move the transform to the server. If the app turns XML into HTML in the browser, do it on the server or at build time and send HTML. This is the clean fix and removes the dependency for good.

Send JSON instead of XML. If the XML comes from your own API, this is often the moment to change the format the front end reads. It's more work than the first option, so do it where you were planning changes anyway.

Add the polyfill. Chrome's page points to a polyfill that runs the same transformation in a safer way; for a styled XML file it's one script line. It buys time without a rewrite. Test it on your real pages, because the polyfill's own documentation lists limits, such as stylesheets loaded from another domain, and put the real fix on next quarter's list.

Whichever you choose, tell your support team before the 17th. Chrome rolls out new versions gradually, so for a week or two some customers will see the feature and others won't. A support script that says "update your browser" will make it worse, because the newest browser is the one where it stops working.

If it's a vendor tool or intranet page you can't edit

For a device admin page, a supplier portal or an old internal system you don't control, you can't add a script line. Two stopgaps exist. An organization that manages its Chrome installs can set the enterprise policy that keeps XSLT on until Chrome 176 next August. Chrome's page also lists a browser extension that applies the polyfill to pages you can't change.

Neither is a fix. Use the time to ask the vendor for an update in writing, or to plan the replacement. We wrote about proving an AI-assisted rewrite of an old system produces the same numbers, which applies here if the old tool feeds anything financial.

What to do this week

Check your sitemap and feed. Search the code for the two strings. Make a short list of the internal and vendor tools people open in Chrome and test them with XSLT switched off. If you don't have a developer on call, send those three checks to whoever hosts or maintains your site and ask for a yes or no in writing; it's a short job for them. If everything is clean, you're done. If not, decide which of the three fixes each one gets before November 17.

If an app feature turns out to depend on XSLT, or an old internal tool needs replacing rather than patching, that's the work our web applications team does. Talk to us and we'll look at it with you.

Related work: Sutton Place.