Atom is better than RSS, in ways that matter

# Atom is better than RSS, in ways that matter — Chris Morgan Source: [https://chrismorgan.info/atom%3Erss](https://chrismorgan.info/atom%3Erss) Draft: started2026\-04\-10•Tagged[/atom](https://chrismorgan.info/atom),[/rss](https://chrismorgan.info/rss) [My feeds](https://chrismorgan.info/subscribe#feeds)are Atom feeds\. Everyone with knowledge agrees that Atom is technically superior to RSS\. Everything*should*have switched to it twenty years ago\. All feed readers support Atom just fine \([except in podcasts](https://chrismorgan.info/atom%3Erss#podcasts), for no good reason\)\. Unfortunately, many people continued to write and choose RSS, whether from ignorance of Atom \(please stop calling feeds “RSS”\!\), or from figuring it doesn’t really matter in the end\. Most of the differences are surface\-level, or*in practice*not a problem: - RSS uses a stupid date format? Doesn’t really affect people much\. - RSS doesn’t specify content encoding, so it’s ambiguous as to whether`<description\>`is text or HTML? Used to be a problem, but these days everyone emits and assumes HTML\. In fact, RSS 2\.0 specs settled on it being HTML, though people often use the unreasonably\-popular, wonkily\-versioned, horribly\-named [`content:encoded`](https://chrismorgan.info/content:encoded)to mean that, even though that’s not what it was supposed to mean\. - RSS is a travesty and the name refers to[nine mutually\-incompatible formats](https://web.archive.org/web/20110726002019/http://diveintomark.org/archives/2004/02/04/incompatible-rss), published by a variety of different and competing organisations sometimes even using the same version numbers? Meh, just ignore the XML namespaces, be sloppy, the feeds you want to cope with will be worse\. Resign yourself, it’ll be easier in the long run\. *Seriously*, you may even be able to get away with forgetting that RSS is supposed to be XML\. But what few realise is that some of the differences*matter*\. That due to inconsistent treatment and usage, some reasonable content*cannot reliably be expressed*in RSS, whereas it’s unambiguous in Atom and should always work fine \(and if it doesn’t, it’s unambiguously a bug\)\. So let’s talk about the cases that*matter*\. I would like to convince people to prefer Atom for*useful*reasons, rather than merely ideological purity\. I want RSS*dead*\. ## Title encoding semantics **Précis:**you can’t reliably use characters like`<`or`&`in RSS titles\. Don’t even*try*mentioning HTML tags in titles\. Content management systems normally allow*headings*to contain markup; but they seldom allow*titles*to contain markup\. This is a tragedy\. Many an article calls for`<code\>`or`<em\>`\. I do it often, and I’ve seen a few others do it, but not many\. Atom defines something called*text construct*, where you can specify whether the value is text, entity\-encoded HTML, or XML\-encoded HTML\. Titles are text constructs\. In RSS… well, not even*content*gets encoding semantics, which used to be a real problem, but over time everyone settled on “it’s always HTML”\. So titles*definitely*don’t get encoding semantics\. And different implementations do different things\. Suppose you want to encode this title: > All about the`<xmp\>`element *How are you going to do it?* In Atom, you have three clear choices: 1. Discard the markup, and encode the text as text\.``` <title type="text"> All about the &lt;xmp> element </title> ``` 2. Keep the markup, and entity\-encode the HTML\.``` <title type="html"> All about the &lt;code>&amp;lt;xmp>&lt;/code> element </title> ``` 3. Keep the markup, and represent the HTML as XML\.``` <title type="xhtml"> <div xmlns="http://www.w3.org/1999/xhtml"> All about the <code>&lt;xmp></code> element </div> </title> ``` TODO: survey RSS readers to find out how they handle all of these cases\. *\(This is the biggest reason I haven’t published this previously\. Probably should have by 2020 or so\.\)* Hard mode challenge:`<\_\>::v::<\_\>`,[a real title I used](https://chrismorgan.info/blog/rust-artwork-owl/)\. ## The summary/full item distinction RSS bad, Atom good\. Capiche? 😁 Heuristics, bad for interop,*&c\. &c\.* *I feel like there was a third Difference that Matters that I had in mind at some point\. Maybe I’ll remember it before I publish\.* ## The fly in the ointment: podcasts I must, in good faith, mention podcasts\. Although approximately every single feed reader and open\-source feed\-reading library from the last twenty years supports both RSS and Atom, most of the largest*podcast*feed readers or syndicators only support RSS\. Since this stuff is largely from 20–25 years ago, and I wasn’t paying attention to the space at the time \(few twelve\-year\-olds would\), details are hazy\. Rough timeline: Podcasting started to be a thing\. RSS 2\.0 added enclosures for it\. Atom was designed, to fix most of the problems with RSS\. It stabilised\. Apple released iTunes podcasting stuff only supporting RSS\. The iTunes*client*[got Atom support](https://web.archive.org/web/20160303233239/http://lists.apple.com/archives/syndication-dev/2005/Nov/msg00004.html#:~:text=iTunes%206%27s%20Atom%20support), but the iTunes Music Store did not\. Atom was published as[RFC 4287](https://datatracker.ietf.org/doc/html/rfc4287)\. I have found no clear evidence that the iTunes Music Store \(later the Apple Podcasts catalogue\) ever supported Atom\. And whatever iTunes/Apple Podcasts ever*did*have,[was removed in 2023](https://podcasters.apple.com/4115-technical-updates-for-hosting-providers#:~:text=Atom%20feeds)\. So I want to blame Apple\. They controlled the space in the critical early days, and they ruined it\. Some podcast readers or syndicators support Atom\. Some*claim*to but don’t\. Some \(probably the most important ones\) just don’t\. RSS is a mess\.*Podcast*RSS is even more of a mess\. Frozen in time, hack is piled upon hack to work around RSS’s shortcomings\. *Ugh\.*