Although XQuery was initially conceived as a query language for large collections of XML documents, it is also capable of transforming individual documents. As such, its capabilities overlap with XSLT, which was designed expressly to allow input XML documents to be transformed into HTML or other formats.

The XSLT 2.0 and XQuery standards were developed by separate working groups within W3C, working together to ensure a common approach where appropriate. They share the same data model (XDM), 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 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^{[according to whom?]} in its handling of narrative documents with more flexible structure, while XQuery is stronger in its data handling (for example, when performing relational joins).

XSLT 1.0 appeared as a Recommendation in 1999, whereas XQuery 1.0 only became a Recommendation in early 2007; as a result, XSLT is still much more widely used. Both languages have similar expressive power, though XSLT 2.0 has many features that are missing from XQuery 1.0, such as grouping, number and date formatting, and greater control over XML namespaces.^[9][10][11] Many of these features were planned for XQuery 3.0.^[12]

Any comparison must take into account the version of XSLT. XSLT 1.0 and XSLT 2.0 are very different languages. XSLT 2.0, in particular, has been heavily influenced by XQuery in its move to strong typing and schema-awareness.

Usability studies have shown that XQuery is easier to learn than XSLT, especially for users with previous experience of database languages such as SQL.^[13] This can be attributed to the fact that XQuery is a smaller language with fewer concepts to learn, and to the fact that programs are more concise. It is also true that XQuery is more orthogonal, in that any expression can be used in any syntactic context. By contrast, XSLT is a two-language system in which XPath expressions can be nested in XSLT instructions but not vice versa.

XSLT is currently stronger than XQuery for applications that involve making small changes to a document (for example, deleting all the NOTE elements). Such applications are generally handled in XSLT by use of a coding pattern that involves an identity template that copies all nodes unchanged, modified by specific templates that modify selected nodes. XQuery has no equivalent to this coding pattern, though in future versions it will be possible to tackle such problems using the update facilities in the language that are under development.^[14]

XQuery 1.0 lacked any kind of mechanism for dynamic binding or polymorphism; this has been remedied with the introduction of functions as first-class values in XQuery 3.0. The absence of this capability starts to become noticeable when writing large applications, or when writing code that is designed to be reusable in different environments.^{[citation needed]} XSLT offers two complementary mechanisms in this area: the dynamic matching of template rules, and the ability to override rules using xsl:import, that make it possible to write applications with multiple customization layers.

The absence of these facilities from XQuery 1.0 was a deliberate design decision: it has the consequence that XQuery is very amenable to static analysis, which is essential to achieve the level of optimization needed in database query languages. This also makes it easier to detect errors in XQuery code at compile time.

The fact that XSLT 2.0 uses XML syntax makes it rather verbose in comparison to XQuery 1.0. However, many large applications take advantage of this capability by using XSLT to read, write, or modify stylesheets dynamically as part of a processing pipeline. The use of XML syntax also enables the use of XML-based tools for managing XSLT code. By contrast, XQuery syntax is more suitable for embedding in traditional programming languages such as Java (see XQuery API for Java) or C#. If necessary, XQuery code can also be expressed in an XML syntax called XQueryX. The XQueryX representation of XQuery code is rather verbose and not convenient for humans, but can easily be processed with XML tools, for example transformed with XSLT stylesheets.^[15][16]

• XQuery 1.0 became a W3C Recommendation on January 23, 2007.^[17]
• XQuery 3.0 became a W3C Recommendation on April 8, 2014.^[18]
• XQuery 3.1 became a W3C Recommendation on March 21, 2017.^[19]

The World Wide Web Consortium (W3C) developed two major extensions to XQuery:

• XQuery 1.0 and XPath 2.0 Full-Text,^[20] which extends XQuery with full-text search capabilities
• XQuery Update Facility, which enables data modification in XQuery

Both became W3C Recommendations as extensions to XQuery 1.0. Efforts to adapt them for XQuery 3.0 were abandoned due to resource constraints.

A scripting (procedural) extension for XQuery was proposed but never completed.^[21][22]

The EXPath Community Group^[23] develops extensions for XQuery and related standards (XPath, XSLT, XProc, and XForms). The following extensions are available:

• Packaging System,^[24] for managing XQuery libraries and modules.
• File Module,^[25] for file system operations.
• Binary Module,^[26] for handling binary data.
• Web Applications,^[27] for building web-based applications

JSONiq is an extension of XQuery that adds support to extract and transform data from JSON documents. JSONiq is a superset of XQuery 3.0. It is published under the Creative Commons Attribution-ShareAlike 3.0 license.

XQuery 3.1 de facto deprecates JSONiq as it has added full support for JSON.

The EXQuery^[28] project develops standards around creating portable XQuery applications. The following standards are currently available:

• RESTXQ^[29]