Est. 1999 Intermediate

XSLT

The W3C's declarative transformation language for XML - standardized in 1999, built into every major web browser for a quarter century, and still driving publishing pipelines from DocBook manuals to scholarly journals.

Created by W3C XSL Working Group; XSLT 1.0 edited by James Clark, XSLT 2.0 and 3.0 edited by Michael Kay

Paradigm Declarative, Functional (template-rule based)

Typing Dynamic; XSLT 2.0+ adds an optional static type system based on XML Schema

First Appeared 1999

Latest Version XSLT 3.0 (W3C Recommendation, June 2017); XSLT 4.0 in draft

XSLT (Extensible Stylesheet Language Transformations) is the W3C’s declarative language for transforming XML documents into other documents - other XML vocabularies, HTML, plain text, or anything else that can be serialized. A stylesheet is a set of template rules: each rule declares a pattern of nodes it matches and the output to produce for them, and the processor walks the source tree applying whichever rules fit. That rule-based, pattern-matching design made XSLT one of the first declarative, functional languages that millions of working programmers encountered - often without realizing that was what they were writing.

Standardized as XSLT 1.0 in November 1999, the language became a fixture of the XML era: built into every major web browser, embedded in Java and .NET class libraries, and load-bearing in publishing systems that turn structured documents into websites, PDFs, and ebooks. A quarter century later the browsers are finally removing it, but in the document-processing world XSLT remains what it has always been - the standard way to turn one tree into another.

History & Origins

From DSSSL to XSL (1997-1999)

XSLT’s ancestry runs through SGML, XML’s heavyweight predecessor. SGML had a stylesheet standard, DSSSL (Document Style Semantics and Specification Language), an ISO specification with a Scheme-based transformation language - powerful, elegant, and used by almost nobody outside a small circle of document engineers. One member of that circle was James Clark, who had written the leading DSSSL engine and served as technical lead of the W3C working group that defined XML itself.

When XML arrived, it needed a stylesheet story. Following an August 1997 member submission (“A Proposal for XSL”), the W3C chartered the XSL Working Group, and the first Working Draft appeared in August 1998. Along the way the original proposal split into three coordinated specifications: a language for transforming XML trees, a language for addressing into them, and a vocabulary of formatting objects for print-quality layout. The first two - XSLT 1.0 and XPath 1.0, both edited by Clark - became W3C Recommendations together on November 16, 1999. The third, XSL-FO, followed as part of XSL 1.0 in October 2001.

The split turned out to be one of the most consequential decisions in XML’s history. XSLT escaped its origins as “the transformation half of a stylesheet language” and became a general-purpose XML processing tool, while XPath became shared infrastructure - the addressing language not just of XSLT but later of XQuery, XML Schema, DOM APIs, and countless testing and scraping tools.

Into the browsers and the enterprise (1999-2006)

Adoption was immediate and, at first, messy. Microsoft shipped XSL support in Internet Explorer 5 in 1999 based on an interim working draft - the infamous WD-xsl dialect - before MSXML 3.0 delivered a complete XSLT 1.0 implementation in 2000. Other engines followed with conformant processors, and client-side XSLT became a standard browser capability that survived for two and a half decades.

Outside the browser, implementations multiplied: Apache Xalan in Java and C++, Michael Kay’s Saxon, Daniel Veillard’s libxslt (whose xsltproc command is available on most Unix-like systems), and native support in the Java (JAXP) and .NET class libraries. Because XSLT 1.0 deliberately kept its function library small, the community EXSLT initiative emerged around 2001 to standardize extension functions - dates, string handling, common functions - across processors.

Design Philosophy

Template rules, not control flow

An XSLT stylesheet inverts the usual relationship between program and data. Instead of code that navigates the input and decides what to do, the stylesheet declares rules and lets the shape of the input drive execution:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:template match="/catalog">
    <html>
      <body><xsl:apply-templates select="book"/></body>
    </html>
  </xsl:template>

  <xsl:template match="book">
    <p class="book">
      <b><xsl:value-of select="title"/></b>
      by <xsl:value-of select="author"/>
    </p>
  </xsl:template>

</xsl:stylesheet>

apply-templates says “process whatever is there, with whatever rules match.” Documents with unexpected structure degrade gracefully rather than crashing, and stylesheets can be extended by adding rules rather than rewriting logic - a property borrowed from DSSSL’s rule-based model and well suited to the loosely structured, mixed-content documents XML was designed for.

A functional language in XML syntax

XSLT is functional at its core: variables are immutable once bound, templates are (in the 1.0 model) side-effect free, and the processor is free to evaluate in any order. This drew both admiration and complaints - programmers arriving from imperative languages searched in vain for a way to update a variable in a loop, and the workaround (recursion) taught a generation of web developers their first functional programming. The choice to express the language itself in XML syntax was equally divisive: verbose to write, but it means stylesheets can be generated, validated, and - fittingly - transformed by other stylesheets.

Key Features

Pattern matching: XPath patterns select which template fires for which nodes, with a defined precedence scheme for conflicts and built-in default rules for unmatched content.
XPath integration: all navigation, selection, and (from 2.0) computation is expressed in XPath, shared with XQuery and the rest of the XML stack.
Recursive processing: apply-templates recurses through the tree; named templates and (in 2.0+) real functions support classic functional recursion.
Multiple outputs: XSLT 2.0’s xsl:result-document writes many output files from one run - one source, an entire website of pages.
Grouping: XSLT 2.0’s xsl:for-each-group solved the notoriously painful 1.0 grouping problem (the “Muenchian method” workaround is a small piece of XML folklore).
Streaming: XSLT 3.0 can process documents far larger than memory, with the specification defining which constructs are streamable.
Packages and JSON: XSLT 3.0 adds a package system for modular stylesheets, higher-order functions, xsl:try/xsl:catch, and - via XPath 3.1 maps and arrays - the ability to consume and produce JSON.

Evolution

XSLT’s three major versions trace the arc of the XML era. XSLT 1.0 (1999) was small, universal, and everywhere - the version browsers implemented and never moved past. XSLT 2.0 (January 23, 2007) arrived as part of the coordinated release with XPath 2.0 and XQuery 1.0, bringing sequences, an optional XML Schema-based type system, regular expressions, user-defined functions, and grouping; Michael Kay, whose Saxon processor served as the family’s reference-quality implementation, took over as editor. XSLT 3.0 (June 8, 2017) answered the two loudest criticisms of its predecessors - memory-hungry processing and an XML-only worldview - with streaming and JSON support.

After the W3C working group wound down, stewardship passed to the XSLT and XQuery Extensions Community Group (QT4CG), which is drafting XSLT 4.0 alongside XPath 4.0 and XQuery 4.0. The drafts remain works in progress as of mid-2026.

The most dramatic recent chapter is subtractive. In 2025, Google announced the deprecation of XSLT in Chromium, citing usage of roughly 0.02% of page loads against the security cost of maintaining the aging libxslt C library, and the WHATWG reached broad agreement to remove XSLT from the HTML standard with the other browser engines signaling support. Chrome’s built-in support is scheduled for removal in version 158 in late 2026. Notably, the endgame for client-side XSLT comes with an escape hatch that shows how far the server-side language has traveled: Saxonica’s Saxon-JS runs full XSLT 3.0 in JavaScript, so pages that need transformation in the browser can bring their own processor.

Current Relevance

XSLT has retreated from the browser but not from the document world:

Publishing pipelines: DocBook, DITA (via the DITA Open Toolkit), TEI, and JATS-based journal production all run on mature, actively maintained XSLT stylesheet libraries. Wherever XML is the master format for books, documentation, standards, or scholarship, XSLT is usually the rendering engine.
Active tooling: Saxon implements XSLT 3.0 across Java, .NET, C, and JavaScript and continues to ship new releases; xsltproc remains a standard command-line utility on Unix-like systems.
Enterprise plumbing: integration frameworks such as Apache Camel offer XSLT transformation steps, and enormous amounts of B2B message translation, configuration generation, and legacy data migration still run through stylesheets written years ago and quietly maintained since.
Standards momentum: the QT4CG’s XSLT 4.0 drafts, with regular meetings and public test suites, show a small but committed expert community still advancing the language.

Why It Matters

XSLT’s influence exceeds its current fashion status by a wide margin:

Mainstream functional programming, before it was mainstream. Years before functional idioms swept into JavaScript, Java, and C#, XSLT put immutable variables, recursion, and pattern-driven dispatch in front of ordinary working developers - because it was the only way to restyle an XML document.
The proving ground for XPath. Splitting XPath out of XSLT gave the entire XML stack - and eventually testing frameworks, scrapers, and query tools far beyond XML - a shared addressing language.
The template-rule idea. Processing driven by the shape of the data, with graceful handling of the unexpected, remains one of the most robust patterns ever devised for document processing, and it is why 25-year-old DocBook stylesheets still work against documents their authors never imagined.
A rare case study in web platform subtraction. XSLT is among the very few technologies ever shipped in every major browser and then scheduled for removal - a story that says as much about the web’s shift from XML to JSON and HTML5 as it does about the language itself.

The browsers are moving on, but the presses have not stopped. Somewhere right now a stylesheet written when the specification was new is turning a tree of markup into a book, a manual, or a court record - exactly the patient, declarative work XSLT was designed for in 1999.

Timeline

1997

'A Proposal for XSL' is submitted to the W3C in August by Microsoft, ArborText, Inso, and others; the W3C soon charters an XSL Working Group to design a stylesheet language for XML, drawing heavily on DSSSL, the ISO stylesheet standard for SGML documents

1998

First public XSL Working Draft published in August; the effort is later split into three specifications - a transformation language (XSLT), a navigation language (XPath), and formatting objects (XSL-FO)

1999

XSLT 1.0 and XPath 1.0 become W3C Recommendations on November 16, with James Clark as editor of both specifications

2000

Microsoft's MSXML 3.0 ships a complete XSLT 1.0 implementation, replacing the earlier draft-based 'WD-xsl' dialect that Internet Explorer 5 had shipped in 1999; browser support for client-side XSLT eventually spreads to all major engines

2001

The full Extensible Stylesheet Language (XSL 1.0, including XSL-FO) becomes a W3C Recommendation on October 15; around the same time the community EXSLT initiative begins standardizing extension functions across XSLT processors

2007

XSLT 2.0 becomes a W3C Recommendation on January 23, published alongside XPath 2.0 and XQuery 1.0 with a shared data model, XML Schema-based type system, and function library; Michael Kay of Saxonica serves as editor

2017

XSLT 3.0 becomes a W3C Recommendation on June 8, adding streaming transformation of documents too large for memory, packages for modular stylesheets, higher-order functions, try/catch error handling, and JSON support via maps and arrays

2025

Google announces the deprecation of XSLT in Chromium, citing low usage and the security burden of the aging libxslt C library; the WHATWG reaches broad agreement to remove XSLT from the HTML standard, with other browser engines signaling support

2026

Chrome schedules the removal of built-in XSLT for version 158 in late 2026, ending roughly 25 years of native browser support; meanwhile XSLT 4.0 remains under active development as a draft by the W3C XSLT and XQuery Extensions Community Group (QT4CG)

Notable Uses & Legacy

DocBook publishing toolchains

The DocBook XSL stylesheets are one of the most widely deployed XSLT codebases ever written, used for decades by open-source projects and publishers to turn DocBook XML into HTML, man pages, ePub, and print-ready output.

Web browsers

Every major browser engine eventually shipped a built-in XSLT 1.0 processor, used for client-side transformation of XML documents and for styling RSS and Atom feeds - a capability now scheduled for removal from Chromium in late 2026.

DITA Open Toolkit

The standard open-source publishing engine for the DITA technical-documentation architecture uses XSLT stylesheets to transform DITA content into HTML5, PDF, and other deliverables for enterprise documentation teams.

Scholarly and legal publishing

Journal production systems built on the JATS XML standard, as well as legal and legislative publishers whose master content is XML, rely on XSLT pipelines to generate web, print, and archival renditions of structured documents.

TEI and the digital humanities

The TEI Consortium maintains a large open-source XSLT stylesheet library that converts TEI-encoded scholarly texts into HTML, PDF, and ePub, underpinning digital critical editions and text archives at universities worldwide.

Enterprise integration middleware

Integration platforms such as Apache Camel expose XSLT as a built-in message-transformation step, and IBM's DataPower gateway appliances made high-throughput XSLT processing a core feature for enterprise XML traffic.

Language Influence

Influenced By

DSSSL

Running Today

Run examples using the official Docker image:

docker pull klakegg/saxon:latest

Example usage:

docker run --rm -v $(pwd):/src klakegg/saxon xslt -s:input.xml -xsl:stylesheet.xsl

Docker Hub → New to Docker?

Last updated: July 22, 2026