Chrome 158 drops client-side XSLT; sites pushed to server-side transforms

Chrome 158 stops applying XSL stylesheets

On 17 November 2026, with the release of Chrome 158, the browser will stop applying XSL stylesheets to XML pages. Any site that serves XML with a linked .xsl file — product catalogues, documentation dumps, readable copies of data files — will find that visitors no longer see the styled result. According to a migration guide published on dev.to, the cut-off is firm, though two escape hatches exist: sites enrolled in an origin trial, and browsers governed by an enterprise policy, keep XSLT working until Chrome 176, due 17 August 2027.

Four routes Chrome offers

The dev.to article relays Chrome's announcement, which lays out four options for affected site owners: run the transformation on the server and send plain HTML; add the xslt-polyfill script to the XML document so the stylesheet is applied again in the browser; serve JSON instead of XML and render it with JavaScript; or run XSLT inside the page with a JavaScript library, of which the announcement names Saxonica's as the largest, with full XSLT 3.0 support.

The polyfill is the smallest change, the guide notes, but like any JavaScript approach it still runs in every visitor's browser. Server-side transformation takes more work, yet it is the only route whose output no longer depends on what any browser supports.

Server-side with PHP, Python or Node.js

In PHP, the XSL extension's XSLTProcessor class takes the XML and XSL documents and returns an HTML string to send as text/html. The extension must be compiled in with --with-xsl, and the author warns it was absent from the official WordPress Docker image for PHP 8.3 they had at hand, so that example follows the PHP manual rather than a verified run.

Python's lxml provides the XSLT class, backed by libxslt. The author ran this path on Python 3.14.3 with lxml 6.0.2 and got the expected HTML table. Node.js has no built-in processor, so a package such as saxon-js or xslt-processor is required.

Two XSLT gotchas worth knowing

Sitemaps place their elements in a default namespace, and XPath 1.0 — the expression language of XSLT 1.0 — ignores default namespaces entirely. A stylesheet must declare a prefix and select s:urlset/s:url rather than urlset/url, or the resulting table comes back empty. That, the guide explains, is the classic reason a sitemap stylesheet silently produces nothing.

Second, libxslt output carries no DOCTYPE, and as MDN documents, a page without a doctype renders in quirks mode rather than standards mode. Adding doctype-system="about:legacy-compat" to xsl:output made lxml emit a proper in the author's test, and an exclude-result-prefixes attribute keeps the helper namespace out of the finished markup.

Don't convert sitemaps or feeds to HTML

Search engines and feed readers fetch those URLs, and they need XML. Google's sitemap documentation accepts XML sitemaps, RSS, mRSS, Atom 1.0 and text files — an HTML page is not among them, so replacing /sitemap.xml with HTML breaks crawling to fix a display problem that only affects people. The guide's advice is to keep the XML where it is and, if humans need a readable view, publish the HTML at a separate address and link to it. Styling feeds with CSS still works in Chrome.

Sites that need more time can register for the origin trial and add its token via the Origin-Trial HTTP response header, since XML documents have no HTML head element to hold a meta tag.

Why it matters

Chrome's stated reason is memory safety: libraries such as libxslt are complex, ageing C/C++ code prone to memory-safety bugs, and pulling them from the browser removes a whole class of risk from the rendering path. For site owners, 17 November 2026 is a hard deadline after which styled XML pages silently degrade for most visitors. Server-side transforms are the durable answer, but they come with their own duty of care: run your own stylesheets over your own XML, never a stylesheet supplied by a user, and keep libxslt patched through system updates.