XSLT: Transforming XML with Style

XSLT (Extensible Stylesheet Language Transformations) transforms XML into another format — HTML, plain text, or different XML — using declarative templates and XPath. Worth leading with directly, since it changes the practical calculus around it: native, client-side XSLT support is being removed from every major browser engine, starting with Chrome in November 2026. This post covers how XSLT works, where it’s still genuinely used, and what that removal actually means for anything relying on it.

In this post: A basic example · Browsers are removing native XSLT support · Checking whether you’re actually affected · What to do instead · Where XSLT is still genuinely used · Pros and cons worth weighing today · Related reading

A basic example

XML input:

<books>
    <book>
        <title>XML Guide</title>
        <author>John Doe</author>
    </book>
    <book>
        <title>XSLT Mastery</title>
        <author>Jane Smith</author>
    </book>
</books>

An XSLT stylesheet that turns it into an HTML table:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
        <html>
            <body>
                <h2>Book List</h2>
                <table border="1">
                    <tr><th>Title</th><th>Author</th></tr>
                    <xsl:for-each select="books/book">
                        <tr>
                            <td><xsl:value-of select="title"/></td>
                            <td><xsl:value-of select="author"/></td>
                        </tr>
                    </xsl:for-each>
                </table>
            </body>
        </html>
    </xsl:template>
</xsl:stylesheet>

The `xsl:for-each` loop walks each `book` node and pulls `title`/`author` into a table row — the same declarative, template-matching approach underlies far more complex real-world transforms, just scaled up.

Chrome removes native XSLT support entirely in version 158 (November 17, 2026) — and Firefox and WebKit have both indicated they’ll follow. Anything still doing client-side XSLT in the browser needs a migration plan now, not eventually.

Browsers are removing native XSLT support

Worth a direct, urgent correction to the common claim that “modern browsers support XSLT” — that’s already becoming outdated. Chrome has a confirmed, staged removal timeline: deprecation warnings started in Chrome 143 (December 2025), Canary/Dev/Beta channels began disabling it by default in Chrome 145, an enterprise policy for temporary opt-back-in went live in Chrome 146 (March 2026), and full removal lands in Chrome 158 on November 17, 2026. The stated rationale is blunt: a 27-year-old parser handling untrusted input for roughly 0.02% of page loads is a hard security tradeoff to keep justifying. Firefox and WebKit (Safari) have both indicated they intend to follow Chrome’s lead and remove XSLT from their engines too — this isn’t a single-vendor decision being made in isolation. Edge, built on Chromium, is expected to follow the same removal timeline as Chrome.

This specifically affects client-side XSLT — the `XSLTProcessor` JavaScript API and the `` processing instruction browsers currently use to transform XML directly in the page. It has no bearing on server-side XSLT processing (Saxon, Xalan, `lxml`, `System.Xml.Xsl`), which isn’t affected by any of this and keeps working exactly as it does today.

Checking whether you’re actually affected

Worth checking explicitly rather than assuming either way — three concrete things to search a codebase or CMS for:

A `` processing instruction inside an `.xml` file — the classic pattern for making a raw XML file render styled when opened directly in a browser (RSS/Atom feeds are the most common surviving example).
`XSLTProcessor` used anywhere in client-side JavaScript — a direct API call, not something that shows up as a dependency in a package manifest.
Any admin console, portal, or CMS still on a classic/legacy UI mode — these are disproportionately likely to still do XSLT rendering in the browser, since it was a common pattern in web software built during XSLT’s peak adoption years.

Server-side XSLT calls — a build script, a backend service, an ETL pipeline — won’t match any of the three and aren’t affected by this at all, regardless of how much XSLT they use.

What to do instead

Move the transformation server-side. Run the same XSLT stylesheet through a server-side processor (Saxon, `lxml`, `System.Xml.Xsl`) and ship the already-transformed HTML to the browser — the stylesheet logic itself doesn’t need to change, only where it runs.
Replace it with a JavaScript-based transform. For anything genuinely needing client-side processing, a JS library that parses XML and builds DOM/HTML directly replaces the browser’s native XSLT engine.
Audit for the classic culprits first. RSS/Atom feeds styled via `` for direct browser viewing, and legacy CMS or portal software (including classic-era SharePoint XSLT list views) are the most common places client-side XSLT still quietly runs — worth checking explicitly rather than assuming it’s not in use anywhere.

Chrome’s enterprise policy and origin trial windows exist specifically to buy migration time, not as a permanent opt-out — worth treating the 2026 date as a real deadline for anything client-side, not an indefinitely postponable one.

Where XSLT is still genuinely used

Server-side data exchange — healthcare (HL7), finance, and government systems that standardized on XML years ago and still transform it between formats, entirely server-side.
Middleware and integration platforms — BizTalk, Apache Camel, and similar tools use XSLT for message transformation between systems, unaffected by any browser change.
Document generation — producing PDFs, formatted reports, or Excel exports from XML sources via a server-side pipeline.
Legacy enterprise configuration — plenty of XML-based config still gets reshaped or extracted via XSLT in build and deployment tooling.

None of these run in a browser, which is exactly why they’re unaffected by the removal above — worth keeping that distinction clear when deciding whether a given XSLT use case needs to change at all.

Pros and cons worth weighing today

Genuinely still true: a declarative, rule-based approach that cleanly separates content from presentation, real XPath-driven precision for selecting XML nodes, and mature server-side processor support across Java, .NET, and Python. Genuinely worth weighing against that: verbose XML-based syntax next to something like JSONPath, weaker debugging tooling than general-purpose languages offer, and now a hard browser-support cutoff for anything client-side — a new, concrete downside that didn’t exist a couple of years ago and changes the calculus for any new project considering XSLT specifically for in-browser transformation.

List View Formatting — how modern SharePoint replaced XSLT-based list view rendering with JSON view/column formatting, for anyone maintaining a classic SharePoint XSLT list view specifically.

XSLT itself isn’t going away — server-side processors keep working exactly as before. What’s actually ending is the browser’s native ability to run it directly against XML in the page, and that clock is now on a fixed, publicly committed schedule rather than an open-ended “someday.”