| XSLT | |
|---|---|
| Paradigm | Declarative |
| Developer | World Wide Web Consortium (W3C) |
| First appeared | 1998 |
| Stable release | 3.0
/ June 8, 2017 |
| Filename extensions | .xsl, .xslt |
| Website | www |
| Major implementations | |
| libxslt, Saxon, Xalan | |
| Influenced by | |
| DSSSL | |
| XSLT | |
|---|---|
| Filename extension | .xsl, .xslt |
| Internet media type | text/xml, application/xml, text/xsl, application/xslt+xml |
| Uniform Type Identifier (UTI) | org.w3.xsl |
Extensible Stylesheet Language Transformations (XSLT, also XSL(T) or XSL-T), is a domain-specific declarative programming language that transforms text into text.
It was originally designed for transforming XML documents into other XML documents, or other formats such as HTML for web pages, plain text, or XSL Formatting Objects. These formats can be subsequently converted to formats such as PDF, PostScript, and PNG. Support for JSON and plain-text transformation was added in later updates to the XSLT 1.0 specification.
XSLT 3.0 implementations support Java, .NET, C/C++, Python, PHP and NodeJS. An XSLT 3.0 JavaScript library can also be hosted within the web browser.
Modern web browsers include native support for XSLT 1.0. However usage has always been rather low and declining. It was used by 0.02% of websites in 2013 and 0.001% in 2025. Over the years XSLT repeatedly had severe security vulnerabilities. Google proposed to remove it from Chromium initially in 2013 and later in 2015. Ten years later, after Firefox and WebKit teams indicated their support for removing XSLT, Google published a deprecation plan in October 2025. A polyfill can be used to support even newer versions of XSLT without native support.
The XSLT document transformation specifies how to transform an XML document into new document (usually XML, but other formats, such as plain text are supported). Typically, input documents are XML files, but anything from which the processor can build an XQuery and XPath Data Model can be used, such as relational database tables or geographical information systems.
While XSLT was originally designed as a special-purpose language for XML transformation, the language is Turing-complete, making it theoretically capable of arbitrary computations.
XSLT is often ambiguously referred to as XSL. This is due to XSL-FO using XSLT, the text/xsl media type, the more common filename extension .xsl and xsl: as namespace identifier in official resources, where every tag in the entire XSLT document is prefixed with xsl:. SAP even refers to it as ".xsl language" on its website.
XSLT is influenced by functional languages, and by text-based pattern matching languages like SNOBOL and AWK. Its most direct predecessor is DSSSL, which did for SGML what XSLT does for XML.

The XSLT processor takes one or more XML source documents, plus one or more XSLT stylesheets, and processes them to produce one or multiple output documents. In contrast to widely implemented imperative programming languages like C, XSLT is declarative. The basic processing paradigm is pattern matching. Rather than listing an imperative sequence of actions to perform in a stateful environment, template rules only define how to handle a node matching a particular XPath-like pattern, if the processor should happen to encounter one, and the contents of the templates effectively comprise functional expressions that directly represent their evaluated form: the result tree, which is the basis of the processor's output.
A typical processor behaves as follows. First, assuming a stylesheet has already been read and prepared, the processor builds a source tree from the input XML document. It then processes the source tree's root node, finds the best-matching template for that node in the stylesheet, and evaluates the template's contents. Instructions in each template generally direct the processor to either create nodes in the result tree, or to process more nodes in the source tree in the same way as the root node. Finally the result tree is serialized as XML or HTML text.
XSLT uses XPath to identify subsets of the source document tree and perform calculations. XPath also provides a range of functions, which XSLT itself further augments.
XSLT 1.0 uses XPath 1.0, while XSLT 2.0 uses XPath 2.0. XSLT 3.0 will work with either XPath 3.0 or 3.1. In the case of 1.0 and 2.0, the XSLT and XPath specifications were published on the same date. With 3.0, however, they were no longer synchronized. XPath 3.0 became a Recommendation in April 2014, followed by XPath 3.1 in February 2017. XSLT 3.0 followed in June 2017.
XSLT functionalities overlap with those of XQuery, which was initially conceived as a query language for large collections of XML documents.
The XSLT 2.0 and XQuery 1.0 standards were developed by separate working groups within W3C, working together to ensure a common approach where appropriate. They share the same data model, type system, and function library, and both include XPath 2.0 as a sublanguage.
The two languages, however, are rooted in different traditions and serve the needs of different communities. XSLT was primarily conceived as a stylesheet language whose primary goal was to render XML for the human reader on screen, on the web (as a web template language), or on paper. XQuery was primarily conceived as a database query language in the tradition of SQL.
Because the two languages originate in different communities, XSLT is stronger in its handling of narrative documents with more flexible structure, while XQuery is stronger in its data handling, for example when performing relational joins.
The <output> element can optionally take the attribute media-type, which allows one to set the media type for the resulting output, for example: <xsl:output output="xml" media-type="application/xml"/>. The XSLT 1.0 recommendation recommends the more general attribute types text/xml and application/xml since for a long time there was no registered media type for XSLT. During this time text/xsl became the de facto standard. In XSLT 1.0 it was not specified how the media-type values should be used.
With the release of XSLT 2.0, the W3C recommended in 2007 the registration of the application/xslt+xml media type and it was later registered with the Internet Assigned Numbers Authority.
Pre-1.0 working drafts of XSLT used text/xsl in their embedding examples, and this type was implemented and continued to be promoted by Microsoft in Internet Explorer and MSXML circa 2012. It is also widely recognized in the xml-stylesheet processing instruction by other browsers. In practice, therefore, users wanting to control transformation in the browser using this processing instruction were obliged to use this unregistered media type.
These examples use the following incoming XML document:
<?xml version="1.0" ?>
<persons>
<person username="JS1">
<name>John</name>
<family-name>Smith</family-name>
</person>
<person username="MI1">
<name>Morka</name>
<family-name>Ismincius</family-name>
</person>
</persons>
This XSLT stylesheet provides templates to transform the XML document:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="xml" indent="yes"/>
<xsl:template match="/persons">
<root>
<xsl:apply-templates select="person"/>
</root>
</xsl:template>
<xsl:template match="person">
<name username="{@username}">
<xsl:value-of select="name" />
</name>
</xsl:template>
</xsl:stylesheet>
Its evaluation results in a new XML document, having another structure:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<name username="JS1">John</name>
<name username="MI1">Morka</name>
</root>
Processing the following example XSLT file
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml">
<xsl:output method="xml" indent="yes" encoding="UTF-8"/>
<xsl:template match="/persons">
<html>
<head> <title>Testing XML Example</title> </head>
<body>
<h1>Persons</h1>
<ul>
<xsl:apply-templates select="person">
<xsl:sort select="family-name" />
</xsl:apply-templates>
</ul>
</body>
</html>
</xsl:template>
<xsl:template match="person">
<li>
<xsl:value-of select="family-name"/><xsl:text>, </xsl:text><xsl:value-of select="name"/>
</li>
</xsl:template>
</xsl:stylesheet>
with the XML input file shown above results in the following XHTML (whitespace has been adjusted here for clarity):
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head> <title>Testing XML Example</title> </head>
<body>
<h1>Persons</h1>
<ul>
<li>Ismincius, Morka</li>
<li>Smith, John</li>
</ul>
</body>
</html>
This XHTML generates the output below when rendered in a web browser.

In order for a web browser to be able to apply an XSL transformation to an XML document on display, an XML stylesheet processing instruction can be inserted into XML. So, for example, if the stylesheet in Example 2 above were available as "example2.xsl", the following instruction could be added to the original incoming XML:
<?xml-stylesheet href="example2.xsl" type="text/xsl" ?>
In this example, text/xsl is technically incorrect according to the W3C specifications (which say the type should be application/xslt+xml), but it is the only media type that is widely supported across browsers as of 2009, and the situation is unchanged in 2021.
XSLT has been criticized as having a steep learning curve, poor readability, poor processing performance, and outdated implementations. In addition, some developers prefer to transform XML using a general-purpose imperative programming language over using XSLT.
Håkon Wium Lie, who was CTO of Opera at the time, said in a 2007 interview that CSS handles most use cases of XSLT.
XSL is a style sheet language often used in print-oriented production lines. CSS and XSL, although sharing a basic formatting model, are quite different in their approach. XSL is a programming language, CSS is not. Is there a need for both languages? I believe CSS can handle most use cases for XSL. For example, Prince has shown that it's possible to create wonderful print publications with CSS. Others will disagree and argue that you, in some cases, need a programming language.
— Håkon Wium Lie, The Future of Web Standards: On the Crisis of the W3C, https://www.heise.de/ct/Redaktion/heb/w3c/lie_english.html
msxsl.exe. The .NET runtime includes a separate built-in XSLT processor in its System.Xml.Xsl library.Muenchian grouping (or Muenchian method, named after Steve Muench) is an algorithm for grouping of data used in XSL Transformations v1 that identifies keys in the results and then queries all nodes with that key. This improves the traditional alternative for grouping, whereby each node is checked against previous (or following) nodes to determine if the key is unique (if it is, this would indicate a new group). In both cases the key can take the form of an attribute, element, or computed value.
The unique identifier is referred to as a key because of the use of the 'key' function to identify and track the group variable.
The technique is not necessary in XSLT 2.0+, which introduces the new for-each-group tag.
The method took advantage of XSLT's ability to index documents using a key. The trick involves using the index to efficiently figure out the set of unique grouping keys and then using this set to process all nodes in the group:
<xsl:key name="products-by-category" match="product" use="@category"/>
<xsl:template match="/">
<xsl:for-each select="//product[count(. | key('products-by-category', @category)[1]) = 1]">
<xsl:variable name="current-grouping-key"
select="@category"/>
<xsl:variable name="current-group"
select="key('products-by-category',
$current-grouping-key)"/>
<xsl:for-each select="$current-group">
<!-- processing for elements in group -->
<!-- you can use xsl:sort here also, if necessary -->
</xsl:for-each>
</xsl:for-each>
</xsl:template>
Although the Muenchian method will continue to work in 2.0, for-each-group Is preferred as it is likely to be as efficient and probably more so. The Muenchian method can only be used for value-based grouping.
The attribute version='1.0' specifies version of XSL(T) specification.
Neben CSS ist XSL bzw. XSLT die zweite Möglichkeit um XML-Daten für den Browser relativ gut darstellbar zu machen. XSL(T) beschreibt dazu die Funktionen und den Syntax der es ermöglicht XML-Elemente in andere Elemente wie z.B. HTML umzuwandeln.
Als Alternative kann ein so genannter XSL(T)-Prozessor benutzt werden. Beim XSL(T)-Prozessor handelt es sich um ein Werkzeug, das ebenfalls ein XSL Stylesheet und ein XML-Dokument entgegennimmt und daraus -- basierend auf den Anweisungen im Stylesheet -- ein neues Dokument erzeugt.
[August 21, 2000] "Inside XSL-T." By Michael Classen. From WebReference.com (August 2000). ['XML may be all the buzz, but a lot of the heavy lifting is actually done with XSL. Extensible Style Sheet Language Transformation sounds like a mouthful, but XSLT is your key to converting XML documents into display languages like HTML.]' "XSL was initially devised to solve two problems: (1) Transforming an XML document into something else. (2) Formatting an XML document for display on a page-oriented device, such as a printer or a browser. Subsequently it has proven difficult to solve the second problem in a fashion that satisfies all the different requirements from low resolution screen displays all the way to hi-res printing and copying. Furthermore, screen formatting is currently done with Cascading Style Sheets (CSS), so little interest developed in yet another method. The World Wide Web Committee (W3C) then decided to split the two tasks into separate sub-standards, XSL Transformations (XSL-T) and XSL formatting objects (XSL-FO). While XSL-T has been an official recommendation since November of last year, XSL-FO is still in the making. A transformation expressed in XSLT describes rules for transforming a source tree into a result tree. The transformation is achieved by associating patterns with templates. Whenever a pattern matches elements in the source tree, a template is used to create part of the result tree. The result tree is separate from the source tree, and their structures can be completely different. In constructing the result tree, elements from the source tree can be filtered and reordered, and new elements can be added. A transformation expressed in XSLT is called a stylesheet in the case where XSLT is transforming into a display language, such as HTML or WML..."
The predominant DSL for XML transformation is XSLT [18], a declarative language based on pattern matching and template instantiation. [from page 6]
Google has sought to drop support for XSLT a few times. In 2013, Adam Barth notified the Blink development list of an intent to deprecate and remove XSLT from the browser engine. Barth argued that the inclusion of XSLT added ""more than its share of complexity, which leads to security vulnerabilities"", and that dropping XSLT support would help to remove Blink's dependency on libxml. Ultimately, the proposal was put on hold. Dominic Cooney tried to deprecate and remove XSLT from Chrome in 2015. After much discussion, Rick Byers replied that Chrome's API owners had met and agreed that they would like to eliminate XSLT from Blink eventually. However, prior experience had taught the team that it was important to do so carefully and with a plan to ""minimize the user and developer pain"". Byers provided a list of components that such a plan would need to have, including real-world case studies for replacements and a deprecation timeline of up to two years. It is unclear if Cooney submitted such a plan, but a decade later Chrome still ships with libxslt and supports XSLT 1.0.
SaxonJS is a high-performance XSLT 3.0 processor that runs either in the browser, or on Node.js. It conforms with the latest W3C specifications (notably XSLT 3.0 and XPath 3.1), together with extensions designed to meet the needs of modern web applications.
The polyfill is powered by a WebAssembly port of the libxslt and libxml2 C libraries, providing a standards-compliant XSLT 1.0 engine.
Existing XSLT 1.0 stylesheets are most often described using the unregistered media type "text/xsl".
Both .xsl and .xslt are valid. The .xsl extension is older and more common in enterprise systems (SAP, Oracle, IBM DataPower). The .xslt extension is more explicit. Saxon accepts either. XSLT Playground accepts any content regardless of what you call it.
Statements are written in .xsl language and the following information explains some of this for admins who are familiar with this language.
Example: Multiple Result Documents
XSLT is a very specialized language with a distinct declarative flavor.
Your server needs to send both the source and the stylesheet with a XML mime type, text/xml or application/xml.
One of the primary criticisms of XSLT is its steep learning curve.
The XSLT syntax is hard to read, and rule-based programming is a concept alien to many programmers.
Processing XSLT stylesheets consumes considerable CPU resources. Scalable applications often require a cache for transformation results in order to achieve the necessary throughput. Another throughput-enhancing option is the use of an XSLT compiler, for example the XSLT compiler contained in XALAN, which translates an XSLT stylesheet into a set of Java classes.
But the truth is that XSLT comes with overhead and architectural constraints that make for big headaches down the road. ... XSLT creates new performance issues that you might never encounter in more direct solutions.
A problem that XSLT adoption has faced comes due to the difficulties in getting older implementations upgraded. Java ships with Xalan. Xalan has not been improved since it was first incorporated into Java back in 2000 and it still uses the very first version of XSLT, standardized in 1999. The Linux based libxslt processor is similar; while it is a good implementation for the Linux platform, it has not been upgraded since it was written in the early 2000s.
Our approach We present a technique, Xact, that combines 1) a full integration of XML values and highly flexible operations for XML transformation into an existing high-level language, and 2) static guarantees of type safety of the transformations. We choose to build on Java since this language is already widely used in development of Web services. Using a general-purpose language allows mixing XML manipulations with other functionality, for example, accessing data bases or communicating on the Internet. [from page 7]
After working through a bit of the XSLT necessary to accomplish something, I concluded that it was easier and simpler to use procedural code to do the same thing.
My conclusion from this exercise was that using Ruby for XML transforms was much easier than using XSLT.