CDATA Section Support: Boosting Apex DOM Classes for XML
Dom.Document classes (and FastXMLDOM) fail to recognize or extract text inside <![CDATA[...]]> tags.
XmlStreamReader class or the XMLDOM.cls wrapper to manually iterate through the XML stream and target the CDATA event type.
I saw this tweet today about the apex-fast-xml-dom library. Unfortunately, it's true that FastXMLDom can’t support CDATA sections as of now. This is because FastXMLDom is a wrapper on top of Spring’10 Apex DOM classes, and DOM classes don’t support CDATA sections.
💡 Status Update (January 2026): It’s been years since, this problem was first visible. However, despite several years of community requests on the IdeaExchange, the native Salesforce Dom.Document classes still do not support CDATA sections. The technical workarounds involving XmlStreamReader remain the industry standard for handling these XML payloads.
In this post, we will see:
What is FastXMLDOM library for Apex?
How to parse XML with CDATA sections in Apex?
Promote the idea of having CDATA support in Apex DOM classes!
For those who don’t know “What is FastXMLDom”!
First, for those who don’t know, what is the FastXMLDom library? It is basically a wrapper on top of Spring’10 DOM classes. You must be thinking, What is the requirement of wrapping the API? Moving further will be a detailed help in CDATA Section Support.
I created this FastXMLDOM wrapper because:
Apex DOM Classes are not following the W3C DOM model and require some learning curve to use. FastXmlDOM is based on the W3C DOM API model, so there is no need to learn a new API.
We all used the awesome XMLDOM.cls library created by RonHess. This library did a great job of saving one from the hassle of using Apex XmlStream classes. But as it's all written in Apex, it shares the “Script Statements” governor limits with your code. This doesn’t hurt in general, but for huge XML responses, it can be a trouble.
FastXMLDom uses Spring’10 DOM classes internally, so all heavy-duty operations of parsing the XML string and creating DOM out of it, are taken care of by native system library code. So this library tried to give what XmlDom.cls was giving, with lesser script statement consumption.
Working Around CDATA Limitations in Salesforce Apex
| Method | Supports CDATA? | Governor Limit Impact |
|---|---|---|
| Dom.Document (Native) | ❌ No | Low (Native Library) |
| FastXMLDOM (Wrapper) | ❌ No | Low (Native Base) |
| XmlStreamReader | ✅ Yes | Medium (Requires Loop) |
| XMLDOM.cls | ✅ Yes | High (Script Statements) |
As Spring’10 DOM classes are not supporting CDATA elements as of now, so both DOM classes and FastXMLDom can’t be used for that purpose.
However, one can use XmlStream-based classes, i.e.XmlStreamReader, to parse CDATA information from XML. The good news is that you can use the XMLDOM.cls library from Ron Hess, as this library uses XmlStreamReader internally so one can get CDATA information using it.
Support Idea – We need CDATA section to support Apex DOM Classes!
Apex DOM Classes for XML can be a bit tricky without proper technical knowledge. As XML is a vital medium for integrating external systems with SFDC, having support for CDATA section would be great. As of now, we can’t use DOM classes(+FastXMLDOM) to parse CDATA information; as mentioned, one can use XmlStreamReader or XmlDOM class for the same. But XmlStreamReader is hard to use, and XmlDOM classes can be heavy on script statements for huge XMLs.
So I was planning to add this as an idea on IdeaExchange, but luckily found one about the Apex support class posted. I request you all to please vote up and support this idea.
Looking forward to your views and thoughts on this!
Reference
Let’s Talk!
Drop a note below to move forward with the conversation 👇🏻
