Browser XML support works well for common cases but has enough inconsistencies across engines to cause problems for anyone building production features on client-side XML processing. This note documents the specific caveats I have encountered, grouped by processing stage.
Parsing Caveats
Error reporting varies. DOMParser returns a document with a parsererror element when XML parsing fails, but the format and content of that element differs across browsers. Chrome wraps the error in a div with specific class names. Firefox uses a different structure. Safari uses yet another. If you parse the error message for diagnostic information, test across all target browsers.
Encoding detection. DOMParser respects the encoding declaration in the XML prolog if present. If absent, it defaults to UTF-8. Documents encoded in other character sets without a declaration will produce garbled text or parse errors. Always include an encoding declaration in XML documents intended for browser consumption.
DOCTYPE handling. Some browsers validate or warn about DOCTYPE declarations in parsed XML. Others ignore them entirely. Do not rely on browser-side DTD validation. It is not consistent enough to be useful.
Transformation Caveats
XSLT 1.0 only. No browser supports XSLT 2.0 or 3.0. This is unlikely to change. If your stylesheet uses 2.0 features (grouping, regular expressions, multiple output documents), it will not run in the browser. Check your XSLT version declaration and feature usage before attempting client-side transformation.
document() function restrictions. The document() function loads external XML documents. In browsers, this is subject to same-origin policy. Cross-origin document() calls fail silently, returning an empty node set. If your stylesheet aggregates data from multiple XML files, all files must be served from the same origin.
Disable-output-escaping behavior. The disable-output-escaping attribute on xsl:value-of and xsl:text is not consistently supported in browsers. Some browsers ignore it. Stylesheets that depend on disable-output-escaping for HTML output may produce escaped markup in some browsers. Avoid this feature for cross-browser stylesheets.
Key function performance. xsl:key and the key() function work in browsers but performance characteristics differ. In some engines, large key indexes cause significant memory allocation. Test key-heavy stylesheets with representative data volumes.
Serialization Caveats
XMLSerializer namespace output. When serializing a transformed document, XMLSerializer may add namespace declarations that were not in the original output. This is technically correct per the DOM specification but can produce unexpected xmlns attributes in the serialized string.
Self-closing tags. XMLSerializer produces self-closing syntax for empty elements (<br/>), which can cause rendering issues if the output is treated as HTML rather than XHTML. If you need HTML-compatible serialization, insert the result into a temporary element and use innerHTML instead of XMLSerializer.
Whitespace preservation. Serialization may normalize whitespace differently across browsers. If whitespace is significant in your output (preformatted text, code blocks), verify serialization behavior in each target browser.
General Workarounds
Test early and often. Browser XML behavior is an area where specification compliance varies. Test transformation output in all target browsers during development, not just before release.
Keep stylesheets simple. The simpler the stylesheet, the more consistent the cross-browser behavior. Complex XSLT 1.0 features like generate-id(), key(), and multi-pass processing work but show more behavioral variation than basic template matching.
Cache XSLTProcessor instances. Creating an XSLTProcessor and importing a stylesheet has overhead. If you apply the same stylesheet to multiple documents, reuse the processor instance.
Provide server-side fallback. For critical transformations, consider running the transform server-side and using browser-side XSLT only for preview or interactive features. This ensures deterministic output regardless of browser behavior.
For a complete guide to browser XML processing, see XML in Modern Browsers. For server-side XSLT patterns, see the XSLT workflows reference.