Two Specs, One Job, Eleven Years of Argument

RSS 2.0 was frozen in 2003. Atom was ratified as RFC 4287 in 2005. Neither has won. Neither has lost. That outcome is more interesting than either format.

What the Formats Actually Mandate

RSS 2.0 is a remarkably short specification. Dave Winer published it at Harvard's Berkman Center in 2003, having locked the spec against future revision — an unusual move that was simultaneously its strength and its provocation. The core is a <channel> element containing <item> elements, each carrying <title>, <link>, <description>, and an optional <pubDate> in RFC 822 format. That last detail matters: RFC 822 date strings like Mon, 02 Jan 2006 15:04:05 GMT may use a timezone abbreviation rather than a numeric offset, which parsers have spent years mishandling because abbreviations like EST are ambiguous and underdefined.

Atom, specified in RFC 4287, was ratified by the IETF in December 2005 after roughly two years of contentious drafting by a working group that included Mark Nottingham, Sam Ruby, and others who had grown frustrated with RSS's governance vacuum. Atom mandates RFC 3339 dates — a profile of ISO 8601 using unambiguous numeric offsets like 2006-01-02T15:04:05Z. That single change makes date parsing mechanically reliable rather than aspirationally reliable. Atom also requires every feed and every entry to carry a globally unique <id> element — a URI that must persist even if a post's URL changes. RSS's <guid> is optional and, by default, treated as a permalink rather than an abstract identifier.

Where They Diverge

The content model is where the philosophical gap opens widest. RSS 2.0 <description> is plain text or HTML but the spec doesn't clearly distinguish which, leaving producers and parsers to guess. Atom's <content> element carries a mandatory type attribute — text, html, or xhtml — so a parser always knows what it is handling. Atom also separates <summary> from <content>, making the full-text versus excerpt question a formal structure rather than an informal convention about what goes in <description>.

Namespace extensibility exists in both formats, but Atom's XML namespace declarations are more strictly scoped, which in practice produces cleaner interoperability when third-party vocabularies like the Podcasting 2.0 namespace bolt on additional elements. RSS has always relied on namespace extensions too — the iTunes podcast namespace being the most consequential — but the base spec's looseness means different producers have interpreted the same fields differently for two decades.

Atom also formalises the <link rel="alternate"> pattern more explicitly than RSS does, and it specifies <link rel="self"> for a feed's own URL, a detail that makes feed aggregators and caching infrastructure considerably easier to implement correctly.

Specifications are argued over in rooms like this one. Atom's took a working group two years; RSS 2.0's had a single author and a closing date.Photo: Kindel Media / Pexels

Why Both Are Still Running

The argument that produced Atom was genuinely productive. RFC 4287 is a more rigorous specification by almost any technical measure — cleaner date handling, mandatory identifiers, unambiguous content types. The IETF process forced precision that Winer's locked-down RSS 2.0 never had to achieve. And yet Atom has not displaced RSS; it runs alongside it across essentially every feed-aware platform in production.

The reason is installed base and simplicity. WordPress, which powers a substantial fraction of the public web, emits both formats. Every podcast in existence uses RSS 2.0 because the iTunes podcast directory standardised on it in the mid-2000s, and that gravity has never shifted — not even the ambitious Podcasting 2.0 project attempted to migrate to Atom. Feed readers like Feedly and Inoreader consume either format without complaint. The practical result is that the format war ended in a draw maintained by inertia, while the intellectual result is that most of the specific problems Atom solved in 2005 are now considered solved regardless of which format a producer happens to emit.

Atom's design influenced how people thought about RSS's weaknesses. Publishers who care about unique identifiers and typed content now build systems that produce clean RSS — with proper GUIDs, consistent date strings, and explicit content wrappers — largely because Atom made explicit what good practice looks like. The eleven years of argument, measured from Netscape's 1999 RDF Site Summary to the point where both formats had achieved stable ubiquity, produced something useful: a baseline of what a syndication format must get right.