Chrome turns off XSLT on 17 November. Check RD Web Access

What happened

Chrome's schedule stops XSLT on Stable in version 158 on 17 November 2026, except for sites in the Origin Trial and browsers under the Enterprise Policy (vendor, Chrome). Microsoft follows: "In Microsoft Edge 159, browser-native XSLT will be off by default in Stable", with rollout from mid-December (vendor, MC1509789).

Google gives its reasons as memory safety bugs in libxslt and low usage, about 0.02% of page loads (vendor, Chrome). That figure is the public web. It says nothing about the intranet page your finance team opens every Monday.

Removed: the XSLTProcessor API and the <?xml-stylesheet type="text/xsl"?> processing instruction. XML itself stays, and so do CSS stylesheets on XML (vendor, Chrome).

Two browsers, one exit

Do not treat mid-December as a safe date for Edge. Microsoft's policy page says that, unconfigured, availability follows the browser default "and any applicable field trials" (vendor). Access Group warns its customers that Microsoft may switch XSLT off for some users that way at any time (vendor, Access Group).

What is confirmed to break

• RD Web Access. Microsoft says it uses client-side XSLT to render, and on Windows Server 2016, 2019, 2022, and 2025 the page fails with "Unable to display RD Web Access". Microsoft is working on a fix and gives no date (vendor, KB5130994).
• Access Mosaic forms. Versions before 26.1 show a blank screen. Upgrade is the permanent fix (vendor, Access Group).

Those are the two we confirmed. The list is not complete. Write-ups point at internal reporting tools, appliance admin pages, and older XML portals as the likely places (independent, eCorp IT). Expect vendors to surface slowly, and check yours rather than wait for a notice.

Find your row

Six steps

Prerequisites: admin rights over Chrome and Edge policy, and a small test group.

1. Step 1. Check RD Web Access today. List every published RD Web URL. Owner: Windows infrastructure lead.
2. Step 2. Reproduce it. Set XSLTEnabled to disabled on a test group and open your internal apps. Better to fail for ten people this week than for everyone on the 17th. Owner: endpoint manager.
3. Step 3. Search the code. Look for XSLTProcessor, type="text/xsl", transformToFragment, and importStylesheet across .xml, .xsl, .js, and .html. For managed fleets, eCorp IT also points to Chrome's Legacy Technology Report (independent). Owner: application owners.
4. Step 4. Decide on the bridge before 17 November. If anything failed, set XSLTEnabled to enabled (REG_DWORD 1 under HKLM\SOFTWARE\Policies\Google\Chrome or \Microsoft\Edge) and restart the browser (vendor). Owner: endpoint manager.
5. Step 5. Ask vendors for a date. Every XSLT-dependent product gets one question: which version removes it, and when? Owner: procurement or the application owner.
6. Step 6. Calendar the real deadline. Put 17 August 2027 on an owned calendar and work back. The policy is a bridge, and Microsoft calls it temporary (vendor). Owner: CIO.

Removing XSLT is the browser's decision. Knowing where you depend on it is yours.

Trade-offs

• Set the policy across the fleet. Fastest and nothing visibly breaks. It also keeps an attack surface Google is removing for security reasons, and hides the audit you still need.
• Set it only for the groups that need it. Smaller exposure. Needs the audit done first, and you have 13 days.
• Move RD Web Access users to the HTML5 client. Microsoft lists this at /RDWeb/webclient/index.html (vendor). It is the option that does not expire, but it has its own setup and may not suit every published resource, so test it.
• Use Edge IE mode for RD Web Access. Microsoft lists it as a workaround (vendor). Edge only, and it adds a legacy dependency to retire later.

Missing

• Microsoft's fix date for RD Web Access. KB5130994 gives none.
• SAP. A knowledge base article surfaced in our search but its page blocks automated reading, so we make no claim about SAP products.
• Whether Firefox and Safari remove XSLT on a matching schedule. We only found second-hand reports.
• A vendor-wide list of affected products. None exists that we could find.
• A test by Prestanda. We have not run these steps in a client estate; the guidance comes from the Chrome and Microsoft documents above.