Feed formats compared: RSS 2.0, Atom and JSON Feed

The Discovery dimension asks whether people and machines can find the work without being told it exists. A feed is the cheapest mechanism for that and the only one a publisher fully controls. There are three formats to choose between, and the choice matters far less than most of the decisions that surround it. This page sets out what actually differs, what to publish, and which parts of the decision the rubric scores.

The short answer

Publish RSS 2.0. If your platform also emits Atom or JSON Feed at no cost, leave them on. Spend the attention you save on the things that are actually scored: whether the feed is valid, whether it is discoverable from the document head, whether the dates are right, and whether it carries full content rather than a teaser.

The JSON Feed authors say the same thing in their own specification: if you can only publish one format, publish RSS, because it is time-tested and universally supported. Anyone already publishing RSS or Atom should keep doing so.

The three formats

All three carry the same information. None of them can express something the others cannot, once namespaces are taken into account. The differences are in how strictly they require it and how unambiguously they express it.

What actually differs

Required fields

RSS 2.0 requires a feed-level title, link and description, and requires almost nothing of individual items. An item needs at least a title or a description; everything else, including a date and a unique identifier, is optional.

Atom 1.0 requires that both the feed and every entry carry a title, a globally unique identifier and a last-updated timestamp. In practice that makes Atom feeds more reliably parseable, because a consumer can depend on an ID and a date being present rather than handling their absence.

JSON Feed sits between the two. It requires a version, a title and an items array, and requires an id on every item, but not a date.

This is the substantive difference between the formats, and it is invisible to a publisher whose platform generates the feed correctly. It becomes visible the moment a hand-rolled feed omits dates and every reader shows the archive in the wrong order.

Content ambiguity

An RSS 2.0 description may contain plain text or escaped HTML, with no way to signal which. A consumer has to guess, and different consumers guess differently. This is the most cited technical criticism of RSS and the reason Atom exists.

Atom specifies content types explicitly through a type attribute taking text, html or xhtml. JSON Feed does the same by having two separate fields, content_text and content_html, so the question cannot arise.

In practice, the RSS ecosystem settled on a convention rather than a fix: <description> carries the summary and <content:encoded>, borrowed from an external namespace, carries the full HTML. Nearly every reader understands this. It works, and it is a convention rather than a specification, which is worth knowing when a feed behaves unexpectedly.

Unique identifiers

How each format identifies an item determines whether a reader shows an edited post as new. RSS uses <guid> with an optional isPermaLink attribute, which is confusing enough that many generators get it wrong. Atom uses <id>, which must be a permanent, never-reused IRI. JSON Feed uses a plain string id.

The rule in all three is the same and is routinely broken: the identifier must not change when the post is edited, and must not be reused when the post is deleted. Feeds that use the URL as the identifier break this rule the first time a slug changes, which is one of several reasons URL stability is a separate concern with its own reference page.

Self reference and relationships

Atom feeds carry a self link, so a consumer always knows the feed’s canonical location even if it was fetched through a proxy or a mirror. RSS commonly adds this by borrowing the Atom namespace, which is standard practice rather than a hack. JSON Feed has a feed_url field for the same purpose.

Atom also has a general link relation model, allowing alternate representations, next and previous pages, and related resources. RFC 5005 builds paged and archived feeds on top of it, which is the only standardised answer to the question of how a consumer reads a ten-year archive through a feed that only holds twenty items.

Attachments and podcasts

RSS allows one <enclosure> per item. Atom allows multiple links with a rel of enclosure. JSON Feed has an attachments array.

For podcasting this is not really a choice. The de facto requirement is RSS 2.0 with the iTunes namespace, because that is what podcast directories parse. A publication with an audio component should not treat feed format as an open question.

Syntax

JSON Feed is functionally equivalent to the other two. Its argument is that JSON is easier to generate and parse than XML for most developers, and that XML has more ways to be subtly malformed. It is not more capable, and its support in readers is real but partial. It is generally shipped alongside RSS rather than instead of it.

Element mapping

If you are moving between formats or reading a feed you did not generate, this is the correspondence:

Autodiscovery, which is the part that is actually scored

A feed that exists at a URL nobody knows is not discoverable. The mechanism is a link element in the document head, present on every page rather than only the home page. This is the cheapest fix in the entire rubric and one of the most commonly missing.

The markup, for each format:

• <link rel="alternate" type="application/rss+xml" title="Feed" href="/feed/">
• <link rel="alternate" type="application/atom+xml" title="Feed" href="/feed/atom/">
• <link rel="alternate" type="application/feed+json" title="Feed" href="/feed.json">

Most platforms emit the first automatically. Custom themes, static site generators and heavily modified templates frequently drop it, and the loss is silent: the feed still works for anyone who guesses the URL, and is invisible to everything that would have found it programmatically.

Full text or excerpt

Every format supports both, so this is a publishing decision rather than a format one. It is also the one part of the feed decision the rubric takes a position on, so the position is worth stating plainly rather than hedging.

The case for excerpts is that a reader must visit the site to finish, which is where the capture unit, the internal links and any commercial surface live. The case for full text is that a feed reader is a reading environment a subscriber chose, and truncating it is a toll on the people most committed to the work.

There is no public evidence settling which produces more revenue, and anyone claiming a universal answer is asserting rather than measuring. What the Discovery band definitions do is take a view about durability rather than conversion: band 5 requires full-text feeds, on the grounds that a feed is a machine-readable copy of the archive under the publisher’s control, and a truncated one is a copy of the headlines. That is a rubric position, it is arguable, and the band definition is the place to argue with it.

What is checkable in either case is which one a publisher chose, and whether that choice is consistent with the rest of their distribution strategy. An excerpt feed alongside no capture unit on the article template is not a strategy, it is a truncation with no purpose.

Feed hygiene

These are the failures that appear repeatedly in teardowns, and none of them are format questions:

• Invalid XML. Usually an unescaped ampersand or a raw character from a paste. Breaks the whole feed rather than one item.
• Wrong or missing dates. Every item stamped with the build time, or dates in a format the specification does not use. Readers sort by date, so this reorders the archive for everyone.
• Relative URLs. A feed is read outside the context of the site. Links and image sources must be absolute or they resolve against the reader.
• Unstable identifiers. Every edit resurfaces the post as new, which reads as spam to a subscriber.
• No conditional GET support. Serving ETag and Last-Modified headers, and answering a conditional request with 304, saves bandwidth on the many clients that poll frequently.
• Item count set too low. Ten items on a publication that posts daily means a reader who was away for two weeks missed the middle.
• Serving the wrong content type. A feed served as text/html or text/plain is not reliably recognised.

The W3C Feed Validation Service checks RSS and Atom against their specifications and is the standard reference for whether a feed is valid rather than merely working in one reader.

What common platforms do by default

The pattern worth noting is that the platforms which handle this well handle it invisibly, and the setups most likely to fail are the ones where someone made deliberate choices about templates. Discovery failures cluster in custom builds, not in defaults.

How this is scored

Discovery band 1 is no feed and no sitemap. Band 2 is one of the two present, with the other missing, invalid or stale. Band 3 requires both present and valid. Bands 4 and 5 are about the hub layer and structured data, with band 5 additionally requiring full-text feeds.

Format choice is not scored. A publication serving only Atom is not marked down against one serving only RSS. What is assessed is whether a feed exists, whether it validates, whether it is discoverable from the head of every page, whether the dates and identifiers are correct, and whether it carries full content.

Publishing no feed at all is scored, and it is scored harshly, because it is the cheapest thing on the entire list to fix.

Questions

Is RSS dead?

No, and the framing is wrong. Feed readers are a smaller consumer category than they were in 2010. Feeds themselves are now infrastructure for a much wider set of consumers: podcast directories, newsletter automation, aggregators, archival services and increasingly the systems that assemble machine-readable summaries of the web. A feed is a machine-readable copy of your archive that you control, which is worth having regardless of how many humans point a reader at it.

Should I publish more than one format?

If your platform generates them for free, yes, and add the autodiscovery tag for each. If publishing a second format means maintaining a second template by hand, no. The marginal reach is small and a stale second feed is worse than no second feed.

Does a feed help with search or answer engines?

A feed is not a substitute for a sitemap and does not serve the same function. A sitemap enumerates the archive for crawlers. A feed advertises what is new, with content attached, and is polled far more aggressively by more kinds of consumer. Publishing both is the band 3 requirement, and neither replaces the other.

Where should the feed live?

Wherever your platform puts it, and then permanently. A feed URL is subscribed to once and polled for years. Moving it without a redirect silently disconnects every subscriber, and none of them will tell you.

Sources

• RFC 4287, The Atom Syndication Format
• RFC 5005, Feed Paging and Archiving
• JSON Feed, Version 1.1
• RSS Advisory Board, RSS 2.0 Specification
• W3C Feed Validation Service
• RSS 2.0 and Atom 1.0 Compared

Specifications and platform defaults verified August 2026. Platform behaviour changes more often than the specifications do, so the defaults table records what was observed on the date given rather than a permanent state.