Skip to content
TrustList
News

Microsoft Edge will switch off built-in XSLT from mid-December

Editorial

By TrustList Editorial

Edge 159 disables the XSLTProcessor API and XSL stylesheet instructions by default. A temporary XSLTEnabled policy buys time until Edge 176 in summer 2027.

About Microsoft Edge will switch off built-in XSLT from mid-December

Microsoft Edge will switch off built-in XSLT from mid-December

15 October 2026: Microsoft will turn off the browser's native XSLT engine by default in Edge 159, rolling out in mid-December 2026, and has told administrators to find any internal or vendor application that still relies on it. A temporary XSLTEnabled policy will keep it working for those who need more time, but Microsoft plans to remove that policy in Edge 176 in summer 2027. The change applies worldwide and in the GCC, GCC High and DoD clouds.

Not yet independently verified. We read the notice through a public archive of the Microsoft 365 Message Center; Microsoft's own copy needs an admin sign-in. Microsoft gives no calendar date for Edge 176 beyond summer 2027. We will update this when it can be confirmed, and remove this note.

What stops working

XSLT is a language for transforming XML into HTML or other XML, and browsers have long been able to run it themselves. Two things are switched off: the XSLTProcessor JavaScript API, and XML processing instructions that point a document at an XSL stylesheet. Instructions that point XML at a CSS stylesheet keep working.

Microsoft's reason is security. The notice says the native implementation rests on an aging native codebase that processes untrusted XML and XSLT, that removing it shrinks the browser's attack surface, and that XSLT has little modern web use. It names the places likely to break: internal websites, public sites, the web interfaces of embedded devices, and third-party web applications.

Where it is likely to turn up

The applications most at risk are old ones. Reports that render an XML feed through a stylesheet, admin pages on printers, storage arrays and industrial controllers, and intranet tools written in the early 2000s are typical users. Many of these come from vendors, so the fix may depend on a supplier rather than an in-house developer.

Microsoft's suggested check uses Lighthouse in Edge's developer tools: run a Best Practices audit on the page, look for "Uses deprecated APIs" and search the report for XSLT or XSLTProcessor. For an application behind a sign-in, Microsoft says to turn off the Clear storage setting so the audit keeps the session. The DevTools Issues and Console panels also show deprecation warnings. Each important workflow should be exercised, since a stylesheet may load only on one report page.

Using the policy without depending on it

Setting XSLTEnabled through group policy or Intune keeps affected applications working after Edge 159, but only until Edge 176. That makes it a bridge for a migration already under way, not a place to park an application nobody owns. Where the dependency sits in a device's built-in web interface, the realistic options are a firmware update from the maker or a server-side transformation, so the conversation with the vendor is worth starting before December.

Related on TrustList:

Sources

Categories & features

TrustList Weekly

The week in software and IT, in one email

The news that matters to buyers, new rankings and our own research. Every Thursday, free, and easy to leave.

We will email you to confirm. Unsubscribe with one click in any issue. Privacy policy