Microsoft is phasing out native XSLT support in Edge, ending decades of compatibility for a web technology that most casual users have never heard of but that some enterprise systems still depend on.
According to reporting from Neowin, the change means a long-standing feature is nearing its end, and enterprise users have a limited window to prepare. That narrow timeline is the key takeaway for organizations whose internal tools still rely on browser-based XML transformations.
What is native XSLT support, and why does Edge keep it?
XSLT stands for XML Stylesheet Language Transformation. It is a W3C-standardized language, first published in 1999, that lets you transform an XML document into another format—most commonly HTML, but also other XML structures or plain text.
In practice, an XML file can carry a reference to an XSLT stylesheet, and a browser that supports XSLT applies that stylesheet on the fly to render the data as a formatted page. This was especially common in the early 2000s, when Internet Explorer shipped with a built-in MSXML parser and a native XSLT engine.
When Microsoft rebuilt Edge on the Chromium platform in 2020, it retained a set of legacy compatibility features so older enterprise and internal tools wouldn’t break overnight. Native XSLT processing was one of those holdovers, preserved for organizations whose applications still parse and transform XML directly in the browser.
Why is Microsoft killing it off?
The short answer is modernization. XSLT is a legacy technology that very few modern web applications use, and maintaining it adds complexity to a browser that is otherwise built on open, standards-based web engines.
Microsoft has a long track record of retiring deprecated features. Over the years it has phased out everything from ActiveX and old Flash-like plugins to various legacy rendering modes, clearing out code that few people still depend on. Native XSLT support fits into that same cleanup effort.
From an engineering standpoint, removing unused capabilities reduces the surface area for security issues and lets the Edge team focus resources on features that actually matter to today’s web. The catch is that “few people use it” still leaves a real, if small, group of enterprise customers who do.
Who is affected, and how much time is there?
For the everyday user, this change is almost invisible. If you browse the modern web, read news, or use cloud apps, you are not relying on browser-native XSLT, and you won’t notice anything different.
The change matters mainly for enterprises and developers who still run internal tools that transform XML in the browser. If an application depends on Edge to parse and render XSLT-styled XML documents, that functionality will stop working once the support is removed.
According to the reporting, Microsoft is giving enterprise users a limited window to prepare. That phrasing suggests the removal will roll out over a period of time rather than appearing all at once, but the message to IT teams is clear: plan for it now instead of waiting for a feature to simply vanish.
What this means for you
If you’re an individual user, there’s nothing to do. Your browsing experience will be unaffected, and you’ll continue to get a faster, more secure Edge.
If you manage a fleet of machines or run internal business applications, though, this is worth a look. Any tool that depends on native XSLT processing in Edge will need to be migrated before the support is pulled.
What you can do about it
The practical move is to audit your applications now. Check whether any internal or third-party tools rely on XML-to-HTML transformation happening inside Edge, and start planning alternatives before the change takes effect.
Possible migration paths include:
- Moving the transformation logic to a server-side process.
- Adopting a JavaScript-based XSLT library that runs in the browser.
- Converting the workflow to a modern data-rendering approach.
Because enterprises are given a preparation window, there’s time to test migrations and coordinate the rollout with your next Edge update cycle. Waiting until the feature is gone is the riskiest option, since legacy XML pipelines can be tricky to rebuild.
For now, the best approach is simple: note the change, inventory anything that depends on it, and start modernizing the parts that do. The technology is decades old, and the web has moved on to better ways of handling data.
Source: Neowin
Over to you: Do you still run any internal tools that depend on browser-based XSLT, or have you already moved everything to the server?
You may also like
Microsoft Edge is rethinking updates for faster protection and fewer interruptions
Microsoft Wants Copilot for Legal Teams to Handle Sensitive Work
Microsoft Edge is working on silent updates that install patches in the background
Firefox Is Building a Private Browsing Lock Feature Chrome and Edge Lack
