Atom is better than RSS, in ways that matter

Atom is better than RSS, in ways that matter Draft: started 2026-04-10 • Tagged /atom, /rss Still needs some polish, a new section, and testing to demonstrate my case. My 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, 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 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, 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: Discard the markup, and encode the text as text. <title type="text"> All about the <xmp> element </title> Keep the markup, and entity-encode the HTML. <title type="html"> All about the <code>&lt;xmp></code> element </title> Keep the markup, and represent the HTML as XML. <title type="xhtml"> <div xmlns="http://www.w3.org/1999/xhtml"> All about the <code><xmp></code> element </div> </title> I’m choosing not to encode > as >: neither HTML nor XML syntax requires it. I get tired of unnecessary overencoding (especially of /, which was never useful); this is mild rebellion, even if in real projects I might encode it. 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. 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 r