Sometime in the next few weeks your browser will stop doing something it has done without being asked since 1999. No pop-up, no setting to flip, no permission prompt. Chrome stops running XSLT on November 17, 2026, and Microsoft Edge follows at version 159. For most of us nothing visibly changes. For a specific set of machines in a specific set of offices, a page that works today stops rendering at all.
The cutoff lives in Chrome’s own release calendar, and it is short: Chrome 158 goes Stable on November 17, 2026. I pulled the milestone schedule from Chromium Dash rather than quoting the announcement page, because the schedule is the part that actually matters. Chrome 156 ships on October 20, Chrome 157 on November 3, and that is it. As of this writing there are two Stable releases left before your users lose the feature. If someone on your team is planning a migration sprint for “sometime next year,” that plan is already wrong.
Before we get to the fixes, I want to be honest about the emotional part, because I saw it in the comments on the Chromium thread and in the Reddit thread about government sites: there is real frustration here, and some of it is justified. A twenty-seven-year-old technology does not deserve to be killed for being old. It deserves to be killed when the cost of keeping it exceeds the value of what it does. That is the argument Chrome is making. It is a reasonable argument. It is also, for the people holding the bag, entirely beside the point.
The last time a browser vendor did something this abrupt, it was the other way around. Manifest V2 disappeared and took uBlock Origin with it, and people spent a weekend moving to alternatives. XSLT is the opposite problem: almost nobody noticed it was there, which is exactly why the cleanup is harder. Nobody filed a ticket. Nobody put it in the roadmap. It just shipped, in 1999, and sat in every browser since.
What exactly goes away
Two things, and it matters which one you depend on.
First, the XSLTProcessor JavaScript class. The one you instantiate with new XSLTProcessor(), hand an XML document and an XSL stylesheet to, and get HTML back out of transformToDocument() or transformToFragment(). After the cutoff, that symbol is gone. Code that calls it throws ReferenceError: XSLTProcessor is not defined, and it throws on every page load, not the first time someone clicks the wrong button.
Second, the <?xml-stylesheet type="text/xsl" href="..."?> processing instruction. The line that sits at the top of an XML file and tells the browser “go fetch this stylesheet, then draw the file as a page instead of as a tree of tags.” After the cutoff, the browser ignores it. The file is served exactly the same. The bytes on the wire do not change. The file simply stops being a page and reverts to being raw XML.
Here is the distinction that saves people a lot of panic: <?xml-stylesheet type="text/css"?> is not being removed. CSS still works on raw XML, so you can still style it. What you lose is the transformation. CSS can color the tree; it cannot turn the tree into a table of clickable links. WordPress core’s ticket on this makes exactly that point, and it is the first thing to test on your own sitemap, because it determines whether you have a cosmetic problem or a functional one.
Why they are doing it
The reason is not nostalgia or spite, and it is worth stating plainly because the security argument is the whole justification. Chrome’s XSLT runs on libxslt, which is a C library. Chromium’s own intent-to-remove message says libxslt was unmaintained for about six months of 2025, and describes it as “a complex, aging C codebase of the type notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution.” That is not a code-review complaint. That is a memory-corruption class of bug in a library whose entire job is to parse untrusted input from the network.
The Chrome team also cites CVE-2025-7425 and CVE-2022-22834, both in libxslt. And Ivan Fratric, whose OffensiveCon talk Chrome links to as the motivating example, has spent years demonstrating exactly this class of browser parser bug. When the person who gets paid to break browsers is telling you a parser is the problem, the parser is the problem.
The usage numbers are what make the trade honest. XSLT appears in about 0.02% of page loads, and the processing instruction in under 0.001%. Chromium surveyed roughly 220 sites and reported that about 72% of them keep working with XSLT switched off. That number is the tell. Three quarters of the sites using a browser feature do not actually need it. They are shipping an instruction that a browser dutifully processes into a page that almost nobody opens.
What breaks, and what merely looks broken
The failure mode depends on whether a human or a machine is reading the file. That is the split that matters for planning, and it is the reason this change is quieter than it looks.
Sitemaps. WordPress core has added the XSL instruction to wp-sitemap.xml since version 5.5. Yoast SEO and Rank Math both still emit it. Today you open a sitemap in Chrome and get a tidy table with a heading and striped rows. After the cutoff you get Chrome’s XML viewer: the tree of <sitemap>, <loc> and <lastmod> nodes, unstyled, no error, nothing broken. The file is intact and correct. Googlebot never needed the stylesheet in the first place, and your server sends identical bytes. If nobody on your team ever opens the sitemap in a browser, this is a non-event.
RSS and Atom feeds. Same story with one extra wrinkle: if someone clicks a visible link to the .xml instead of pasting it into a reader, they now see raw XML where they used to see a formatted page. Feed readers do not care at all. Chrome’s own recommendation for this case is to advertise the feed with <link rel="alternate" type="application/rss+xml"> in your HTML rather than exposing a clickable <a href="something.xml">, which is honestly better practice anyway.
JavaScript calling XSLTProcessor. This is the hard break, and it is where the work is. If your application builds a UI or a report by transforming XML in the browser, it throws on load. There is no graceful degradation, no empty state, no error boundary that saves you. The transform has to move.
Server-side XSLT. Nothing. PHP’s ext-xsl, Saxon, xsltproc, Java, .NET, your integration middleware, all of it is untouched. If your XSLT already runs on the server, this change cannot reach you, and that single fact is why the correct answer to most of these situations is boring.
The part nobody tested: internal tools
This is the section I would forward to whoever owns endpoints in your organization.
Microsoft has a support article for it. Windows Server’s RD Web Access, the Remote Desktop web portal, uses client-side XSLT to render its interface. Disable XSLT in the browser and the page does not degrade: it fails to render, and users see an error page. Microsoft’s own guidance to administrators is to set the XSLTEnabled policy to Disabled on a test group now, ahead of the change, specifically to find which internal applications depend on it.
Read that again. The vendor’s recommended preparation is to break the feature early on purpose so you can discover what breaks. That is the correct way to handle an undocumented dependency, and it is the pattern I would copy for anything behind your firewall. The default enterprise answer, “just set the policy to Enabled and keep going,” is available until Chrome 176 on August 17, 2027, and it is a loan, not a solution. It buys you nine months, and the counter starts whether you use the time or not.
Public standards bodies have the same problem. ISO’s maintenance agency published a warning that ISO 1750:2023, a standard whose data set renders through XSLT, would be affected, and is still deciding how to replace the display. Regulators publishing XML data sets built this way have the same exposure as your intranet, except the audience is the public and the fix has to be backwards compatible.
This is also where I stop trusting the comfort metrics. The 0.02% page-load figure is true and it is not the number that decides your week. OpenSSH is a “quiet release” too, and it still changed how a whole class of servers should be run. A feature can be used by almost nobody on the open web and still be the only thing standing between your staff and a working login page.
Your actual options
There are four, and the order is roughly the order you should consider them in.
1. Do nothing. Legitimate for sitemaps and feeds that only machines read. Confirm nobody opens them, delete the instruction if you want to stop shipping a dead request, move on. This is the right answer more often than the outrage suggests.
2. Move the transform to the server. Run the same stylesheet on your backend and send the rendered HTML down. PHP ext-xsl still ships in the PHP manual, libxslt and Saxon are alive and maintained, and the output is plain HTML that no browser feature can ever take away from you. It is testable in CI, cacheable, and free of CORS constraints. It costs you a round trip and, in one specific case I will name because it is the case people get wrong, it costs you a privacy promise: if your tool’s marketing says “the XML never leaves your browser,” that claim stops being true the moment the transform moves server-side. Say so in the UI. That is not a blocker, it is a disclosure.
3. Ship the polyfill. Chrome ships an official polyfill that replaces XSLTProcessor with libxslt compiled to WebAssembly. It is about 1.4 MB minified, it is a one-line drop-in for the JavaScript API, and for a large existing codebase it is a genuine bridge. Chromium’s own analysis says about 75% of sites hitting the use counter do not appear visibly broken, and of the 25% that do, 82% are restored by the polyfill. The 18% that cannot use it mostly fail on CORS restrictions.
Two honest caveats. First, you are now shipping and patching libxslt yourself, which is the exact library the browsers dropped for security reasons. It runs in a sandbox instead of native code, so the risk profile is genuinely different, but “we moved the unmaintained C library into the browser as WASM” is not a sentence you want to defend in a security review without having thought about it. Second, if your stylesheet uses xsl:include, the polyfill fails, because it resolves includes with asynchronous fetch() while the XSLTProcessor methods are synchronous. Flatten the includes into one file and it works. I tested this specific failure mode against a real signed invoice and the polyfill with a flattened stylesheet produced a string the seal verified; with includes intact it did not.
4. Buy time, then do one of the above. The Origin Trial and the XSLTEnabled enterprise policy keep XSLT alive past the cutoff, and both end on Chrome 176 in August 2027. Use that window to migrate properly. Do not use it to migrate never.
How to find out if you are affected
Chrome has been logging a deprecation warning in the console since version 143, and in Lighthouse too. Open your application pages with the console visible and look for “XSLTProcessor and XSLT Processing Instructions have been deprecated by all browsers.” Since Chrome 154, pages rendered through XSLT also get a red banner injected as the first element of the body, which means the warning is now visible to end users and not just to you.
Then grep the codebase. grep -r XSLTProcessor and grep -r xml-stylesheet across your repositories and templates, and do it in the vendor directories too, because a lot of the real exposure is a library you installed in 2019 that nobody remembers. If you want the count without wiring anything up, Chrome’s Reporting API can report XSLT deprecation usage, and the enterprise Legacy Technology Report does the same thing across a fleet.
For WordPress specifically there are official filters to drop the sitemap stylesheet, which saves you the request to the .xsl and silences the console warnings. WordPress core has the change queued in ticket 65593 for version 7.2, and Yoast has an open issue to replace its XSLT stylesheet with CSS. Neither had merged as of mid-September, so if you are on either, plan to act yourself rather than wait for the plugin to save you.
And if your instinct is to just let the browser vendors sort it out, remember that the same vendors are the ones who removed the safety net. Microsoft shipped an agent security layer into Windows 11 this year while separately telling its own enterprise customers to break XSLT on purpose. The platform is hardening around you in both directions at once. Assume nothing is permanent, including the parts nobody told you about.
Common questions
Does this affect Google Search and my rankings?
No. The change lives in the browser. Your server sends exactly the same sitemap bytes before and after November 17, and crawlers that never ran the stylesheet keep receiving the same file. There is no Google Search statement about XSLT and sitemaps, so I am not going to pretend one exists. What is verifiable is that the transform was always a presentation layer for humans, and the ranking system did not depend on it.
Will my RSS subscribers notice?
No. Feed readers fetch the XML directly and do not apply the browser stylesheet at all. The only person affected is a human who clicks a visible link to the .xml and now sees raw markup instead of a formatted page. That is why the recommendation is to advertise the feed with <link rel="alternate"> rather than linking to the file itself.
Is server-side XSLT safe?
Yes, and that is the whole answer for most teams. PHP’s ext-xsl, Saxon, and xsltproc are unaffected. The removal is scoped to the browser’s copy of the processor. If your transformation already runs on your own infrastructure, this change cannot reach you.
What about XML itself?
XML is not going anywhere. Chrome is explicitly keeping XML parsing and the XML + CSS combination. Only the transformation step is being removed. If your application is built on XML as a data format, you are fine. If your application is built on the browser drawing that XML, you are not.
Should I pin an older browser version instead?
You can, and vendors document it as a workaround, but I would not build a plan on it. Freezing a browser version means freezing every security patch that came after it, on machines that handle real data. That is a worse trade than the one you are trying to avoid. If you freeze, freeze for weeks, not quarters, and put a removal date on the calendar the day you do it.
The last word
Nobody is going to write a eulogy for XSLT. That is fine. It did a real job for a long time, and the reason it is going is that the job got handed to better tools while the old one kept collecting security bugs in a library almost nobody was watching. If you run something that depends on it, you have roughly two Stable releases of runway and three boring fixes available. Pick one, and stop reading about it.