Avoid using "<![CDATA[ ... ]]>" in RSS | WaspDev Blog

Home

Projects

Articles

About

⚲

Home→Articles→Avoid using "<![CDATA[ ... ]]>" in RSS

Avoid using "<![CDATA[ ... ]]>" in RSS

Published on 11/05/2026
Updated on 12/05/2026

#rant#rss

<![CDATA[ ... ]]> is very commonly used in RSS (also Atom) feeds to escape XML special
characters. At first glance, it looks very convenient,
you simply add <![CDATA[ ... ]]> blocks and write any (almost) content inside of them without
worrying
about escaping characters:

<item>
<title><![CDATA[Using <CDATA> in Titles]]></title>
<link>http://example.com</link>
<description>
<![CDATA[
<p>This description contains <strong>HTML markup</strong>.</p>
<p>It allows us to use characters like "<b>&</b>" and brackets directly.</p>
]]>
</description>
</item>
Table of contentsWhy not CDATA?What to do instead?ConclusionWhy not CDATA?

CDATA seems to be perfect, isn't it? Except it's not possible to escape some CDATA special character sequences
inside a
single CDATA block, particularly ]]> (the one that ends the CDATA block). In order to do that,
you have to split the CDATA block
into multiple parts:

<text>
<![CDATA[hello ]]]]><![CDATA[> world]]>
</text>

The encoded text is "hello ]]> world". As you can see, the XML code is less readable now. CDATA
loses most of its simplicity advantage.

Even though splitting makes the encoding of ]]> possible, I would say it's still not worth using
CDATA:

It adds a special edge case for ]]>, which the serializer must handle.
It can mislead people into thinking the content is raw HTML or somehow safer. No, it is not.
It makes output less uniform, because sometimes you need split CDATA blocks.
It does not change the parsed value. XML parsers expose the same text either way.
It can make debugging confusing, especially if the content itself discusses CDATA, like this article title
does... Just look at the
RSS feed of this blog.

What to do instead?

Just escape these characters (works for HTML too):

function xmlEscape(text) {
return text
.replaceAll("&", "&amp;")
.replaceAll("<", "&lt;")
.replaceAll(">", "&gt;")
.replaceAll('"', "&quot;")
.replaceAll("'", "&#39;");
}

Normal escaping is simpler and more uniform.

OK, but some people might say that CDATA might make the RSS content smaller on average since
characters don't need any escape (which requires more characters in encoded form) and ]]> is
encountered rarely. Fair point, however:

Feeds are usually gzip-compressed. Repeated strings like &lt;,
&gt;, and
&amp; compress very well.

RSS feed size is rarely the bottleneck. Images, HTML pages, CSS, JS, and network latency
usually matter much more.

CDATA has a special edge case. You still need to correctly handle ]]>.

Normal escaping is simpler and more uniform. One escaping path works for titles,
descriptions, Atom, RSS, attributes, metadata, etc.

Conclusion

Here I listed the reasons why you should avoid using CDATA. This is especially true if you are going to
implement your custom RSS / Atom feed generator.
Many libraries / frameworks / CMSs still generate CDATA for RSS / Atom feeds and many of them handle the
mentioned character sequence
]]> in their own ways. And they are perfectly fine to use if you have to rely on them. CDATA is
common because it
is convenient for legacy feed generators and visually cleaner for embedded HTML. But for new code, ordinary XML
escaping is usually cleaner and more uniform.

See you later.

I'll probably never use Windows

My thoughts on OS-level age verification

Is throwing an exception a faster way to break out of recursion in JavaScript?

Upcoming JavaScript features in 2026

Read previous

Load Disqus comments

Disqus uses cookies, please check Privacy & cookies before loading the comments.

Please enable JavaScript to view the
comments powered by Disqus.

⬆UP

This site uses cookies for some services. By clicking Accept, you agree to their use.
To find out more, including how to control cookies, see here: Privacy & cookies.

Accept

Reject

© 2026, Suren Enfiajyan - RSS / Atom -
Privacy & cookies

CDATA sections are frequently utilized in RSS and Atom feeds to provide a convenient method for escaping XML special characters, allowing content to be inserted without manually escaping characters. This approach appears simple, yet the text argues against its use due to several inherent complexities and potential pitfalls, particularly when considering robust implementation. A significant complication arises because CDATA blocks have limitations regarding escaping specific sequences, such as the closing delimiter of the block itself, namely ]]> which must be handled specially. To accommodate this, developers are often forced to split the content into multiple CDATA blocks, which consequently diminishes the overall readability of the XML structure.

Although splitting resolves the issue with ]]> sequences, the resulting encoded text is less readable, suggesting that CDATA sacrifices its initial advantage of simplicity. Furthermore, the author contends that CDATA introduces an unnecessary special edge case that serializers must manage, potentially misleading users into believing the content is inherently raw HTML or safer than it actually is. This method leads to less uniform output because context demands occasionally require the use of split CDATA blocks. Critically, the author notes that CDATA does not actually change the parsed value, as XML parsers handle the text equally effectively regardless of the encoding method.

Regarding performance, while CDATA might theoretically reduce the character count by avoiding escaping common characters, this benefit is often negligible in real-world scenarios. Since RSS feeds are typically gzip compressed, the size of the feed is rarely the performance bottleneck compared to factors like image size, HTML pages, CSS, JavaScript, or network latency. The main practical drawback remains the complexity introduced by the special handling required for ]]> sequences.

In contrast to CDATA, the alternative of using normal XML escaping involves escaping characters such as ampersand less-than sign greater-than sign double quote and single quote using predefined entities. This standard escaping path is presented as simpler and more uniform, offering a single, consistent method for handling escaping across all parts of the feed, including titles, descriptions, Atom formats, attributes, and metadata. Therefore, the author concludes that while CDATA remains common due to its convenience for legacy feed generators and visual clarity for embedded HTML, ordinary XML escaping is generally cleaner, more uniform, and recommended for new code implementations, especially when building custom RSS or Atom feed generators.