Chrome removes XSLT on November 17: how to audit your site and replace in-browser transforms
Chrome 158 kills the XSLTProcessor API and the xml-stylesheet instruction on November 17, 2026, and Firefox and WebKit are heading the same way. Which classes of sites actually break, the three-check audit we run before every migration, and the three replacement paths — including an emergency bridge that expires in August 2027.
On November 17, 2026, with version 158, Chrome stops running XSLT: both the JavaScript XSLTProcessor API and the <?xml-stylesheet?> instruction that turns an XML file into a rendered page disappear, and Firefox and WebKit have announced they are following the same route. If your site serves XML with a stylesheet, or your JavaScript transforms XML feeds into HTML in the browser, you have a little over a month. The good news: the audit is three checks that fit in an afternoon, an emergency bridge exists (a deprecation origin trial that expires on August 17, 2027), and in most cases the right replacement is not rewriting XSLT in JavaScript — it is stopping transforming in the browser altogether.
What is being removed, and when
It is two APIs, not one. The XSLTProcessor class — what your code calls when it does new XSLTProcessor() to transform XML on the client — and the <?xml-stylesheet type="text/xsl" ...?> processing instruction in top-level XML documents, where the browser itself transforms the document on load. Chrome documents the full removal calendar:
| Date | Version | What changes |
|---|---|---|
| Oct 28, 2025 | Chrome 142 | Early-warning console messages |
| Dec 2, 2025 | Chrome 143 | Official deprecation: console and Lighthouse warnings |
| Mar 10, 2026 | Chrome 146 | Enterprise policy live for testing early disablement |
| Aug 25, 2026 | Chrome 152 | Origin trial live: lets sites keep using XSLT past Nov 17 |
| Sep 22, 2026 | Chrome 154 | Webview Canary, Dev and Beta channels disable XSLT by default |
| Nov 17, 2026 | Chrome 158 | XSLT stops working on stable for everyone not on the origin trial or enterprise policy |
| Aug 17, 2027 | Chrome 176 | Origin trial and enterprise policy expire: XSLT off for everyone |
This is not a Chromium-only decision. Mozilla has an open tracking bug for deprecating and removing XSLT, and its official position in the WHATWG discussion is that removal is "good for the long-term health of the web platform and good for user security" — noting that XSLT usage is now lower than Mutation Events were when those were removed, and that Flash, which did get switched off, was used vastly more. WebKit has already merged a console deprecation warning that fires whenever a developer touches an XSLT API. And Edge is not sitting it out: it published the XSLTEnabled enterprise policy to manage the transition, and Edge 147 had already dropped XSLT-based inline SVG production.
The stated motive is security. libxslt and libxml2 have been in maintenance mode for years and have been a repeated source of incidents; Chrome also plans to move XML parsing off libxml2 onto a parser written in Rust. When all three engine projects agree a technology has to go, the date stops being a recommendation.
What actually breaks (and what does not)
Not everyone uses XSLT, and whoever does almost never knows it: it usually arrives through an inherited template, a third-party widget, or an XML file nobody has touched in a decade. These are the four classes we find when auditing dependencies, in order of severity:
| Case | Real example | What happens on Nov 17 | Severity |
|---|---|---|---|
| Decorative XML | sitemap.xml with a stylesheet | The browser shows raw XML instead of the formatted page; crawlers read the XML directly and are unaffected | Low |
| Functional document rendering | Catalogs, directories or legislation served as XML + XSL — the US Congress site serves its bills this way | The user stops seeing a page and starts seeing XML markup or a notice | High |
XSLTProcessor inside your JavaScript | XML feeds turned into HTML on the client, master tables, in-browser PDF generators | Your JS throws and the content simply never appears | High |
| Internal apps and devices | Remote desktop web clients, network device panels that serve XML with XSL | Interface unusable in Chrome; Microsoft's support forums already show the "XSLT is being removed" message right when users open those clients | Critical |
The fourth row is where enterprises will get the most surprises: internal web applications nobody has touched in years that depend on a stylesheet just to show a login screen.
The audit: three checks
This is the list we add at the start of any legacy site review before proposing a migration. Nothing here needs special access.
1. Search for the signature in your code and in the XML you serve. One grep covers 90% of cases:
grep -riE "xml-stylesheet|XSLTProcessor" --include="*.js" --include="*.xml" --include="*.xsl" --include="*.html" .
Also check the XML you deliver over HTTP — feeds, sitemaps, catalogs — for the <?xml-stylesheet?> instruction in the header.
2. Read the Chrome console. Since Chrome 143, XSLT deprecation warnings appear in the console, and Lighthouse reports them in audits. This is the best detector of forgotten dependencies: the warning fires even when the XSLT comes from a third-party widget you never touched, because the entity doing the transformation is the browser, not your code.
3. Classify before deciding. The same plan does not fit a sitemap and an internal app login:
| Class | How you recognize it | What to do before Nov 17 |
|---|---|---|
| Decorative | Only changes the appearance of an XML; the content reads the same untransformed | Do nothing, or generate the HTML at build time if you care about the view |
| Functional | Without the transform the user does not get a usable page | Move the transform to build time or to the server |
| Critical | Login, dashboard or internal flow that does not work without XSLT | Dated plan: real migration, or an origin trial token as a bridge |
Three replacement paths (and a bridge)
Once classified, the path is chosen with two questions: does the data vary per user or per request? Do you control the build?
| Situation | Path | When to pick it |
|---|---|---|
| Stable XML and XSL, everyone gets the same output | Transform at build time: a loader converts XML to JSON or HTML during compilation | Most sites; the default path in Astro or Next.js |
| The feed changes and you do not control when it compiles | Transform on the server or in a Worker before responding | Live feeds, third-party data, inventories |
| You just map fields from a small XML | DOMParser plus a thin JavaScript layer | When the "transform" is really reading five fields |
| You cannot touch it in time | Deprecation origin trial (per-origin token) or enterprise policy | Bridge until August 17, 2027 — never the final solution |
Two notes on the bridge. The origin trial token is requested from Chrome's origin trials dashboard, injected per origin, and works until Chrome 176 (August 17, 2027); the enterprise policy covers managed environments, which is exactly the internal-equipment case. On polyfills: they reasonably cover XSLTProcessor() when your JavaScript calls it, but the declarative instruction in top-level documents is far harder to simulate, and Mozilla is debating exactly that in its tracking bug — there is a polyfill extension in testing for Firefox, but depending on a user-installed extension is not a production strategy.
Our position: do not port XSLT to JavaScript
Rewriting hundreds of lines of XSLT —XPath 1.0, templates, modes, keys— by hand with DOMParser is where almost every migration project stalls: it is weeks of work, not days, and the result is code nobody wants to maintain afterwards. Our rule is different. If the XML and the XSL do not vary per user, move the transform to build time and store the resolved HTML or JSON. The new site should not know a runtime transform ever existed. Only when the data is live and you do not control compilation does transforming on the server make sense; only when the "transform" is field mapping is DOMParser worth it. And the origin trial token is requested the day there is no other option, not the day the project starts: it is a crane, and cranes expire on August 17, 2027.
How we fold this into every migration
When we pull content out of a legacy CMS — our WordPress to Astro migration of 2,500 pages cost five extra days just on formats no parser understood — the "what depends on the browser" review was already part of the diagnosis. What changes now is the urgency: before November, a browser-side transform was silent debt; after it, it becomes a breakage with a date.
That is why the pre-review includes the grep above alongside the questions we already ask about how content behaves without JavaScript and where logic lives in a Cloudflare architecture. And if the legacy site has to stay alive a few more months while we migrate — that was exactly the case in our own jump to Cloudflare Pages — the origin trial bridge buys time, but only if you request it before November 17.
Before November 17, in order
- Run the grep across the repository and the XML you serve over HTTP.
- Open your XML pages in Chrome and read the console.
- Classify every finding as decorative, functional, or critical.
- For the functional ones: transform at build time, or on the server if the data is live.
- For the critical ones with no migration time: request the origin trial token this week.
Five steps, an afternoon's work on most sites, and the difference between finding out on November 17 with users watching, or finding out now.
Frequently Asked Questions
What exactly does Chrome remove on November 17, 2026?
Two APIs, not one: the JavaScript XSLTProcessor class your code calls to transform XML on the client, and the xml-stylesheet processing instruction in top-level XML documents, which makes the browser itself transform the page on load. From Chrome 158 neither works, except for sites enrolled in the deprecation origin trial or covered by an enterprise policy.
Will my sitemap.xml stop working?
No. The sitemap remains a valid XML file and crawlers read it without going through XSLT. The only change is what a human sees in the browser: instead of Google's styled page you get raw XML or a notice. It is the lowest-severity case of all four.
How do I check in an afternoon whether my site depends on XSLT?
Three checks: grep for xml-stylesheet and XSLTProcessor in your code and in the XML you serve; open your XML pages in current Chrome, which has shown deprecation warnings since Chrome 143 even when the XSLT comes from a third-party widget nobody remembers; and classify what you find as decorative, functional, or critical before choosing a replacement.
