You probably haven't seen the term RSS in years. If you started using the internet after 2013, you may have never seen it at all. This post isn't going to try to convert you back to RSS — it's not a better choice, just a different one. And it's the most important forgotten choice the internet ever made. RSS is a protocol, an XML file, a way to get content without being asked "who are you." Here's where it came from, how it works, why it faded, and where it still lives.

1. Where RSS Came From

In 1999, engineers at Netscape designed an XML format for the My Netscape portal page, allowing external website content to automatically aggregate onto the portal. The format was called RDF Site Summary, later known as RSS 0.90.

One key design decision was set from day one: it's purely client-side pull. The website puts an XML file at some URL; the client periodically fetches it. No central server, no user registration, no authentication. This was the default decentralized model of the early internet.

But the standard's evolution wasn't a straight line. After RSS 0.90, Netscape abandoned it. Another group took over and pushed through versions 0.91 to 2.0. Meanwhile, a separate community argued RSS needed stricter semantics and released RSS 1.0. Awkwardly — RSS 1.0 and RSS 2.0 have no inheritance relationship. They're two incompatible formats that both happen to be called RSS.

This fragmentation was eventually resolved by an outside contender. In 2005, Google proposed Atom — a more cleanly designed syndication format, standardized by the IETF (RFC 4287), avoiding all the versioning mess. Most readers today support both RSS 2.0 and Atom; new systems almost exclusively choose Atom.

That same year, Google launched Google Reader — a web-based RSS aggregator, incredibly clean and usable. RSS went from a protocol requiring a dedicated client to a web page in your browser. The golden age of RSS had arrived: major news portals, personal blogs, and academic sites displayed that little orange icon prominently; feed subscription was a default configuration.

Then on July 1, 2013, Google shut down Google Reader. Users had three months to export their subscription lists.

2. Opening Up the Protocol: What RSS Looks Like

At its core, RSS is just an XML file. Sitting at some public URL. With a fixed structure.

A typical RSS 2.0 feed looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>My Blog</title>
    <link>https://example.com</link>
    <description>About tech and other things</description>
    <lastBuildDate>Mon, 19 May 2026 08:00:00 GMT</lastBuildDate>
    <item>
      <title>A New Post</title>
      <link>https://example.com/posts/new-post</link>
      <guid>https://example.com/posts/new-post</guid>
      <pubDate>Sun, 18 May 2026 12:00:00 GMT</pubDate>
      <description>Summary or full text of the post</description>
    </item>
  </channel>
</rss>

The structure is remarkably flat. <channel> describes feed metadata, <item> represents individual entries. Each item has a title, link, unique identifier (guid), publication date, and summary.

The Atom version is semantically cleaner:

<feed xmlns="http://www.w3.org/2005/Atom">
  <title>My Blog</title>
  <link href="https://example.com" rel="alternate"/>
  <updated>2026-05-19T08:00:00Z</updated>
  <entry>
    <title>A New Post</title>
    <link href="https://example.com/posts/new-post" rel="alternate"/>
    <id>https://example.com/posts/new-post</id>
    <published>2026-05-18T12:00:00Z</published>
    <summary>Summary or full text of the post</summary>
  </entry>
</feed>

Key differences: Atom uses <entry> instead of <item>, requires id to be a URI, uses RFC 3339 timestamps instead of RSS's RFC 822, and Atom's <content> can carry full HTML body text while RSS 2.0's <description> is only an optional summary field.

But the point isn't these differences. The point is: that's the entire mechanism. No handshake, no authentication, no session. A client visits a URL, gets XML, parses out content. From a protocol design perspective, its complexity is close to zero.

XML may look like a relic today, but RSS uses XML for two hard reasons: rich text content (HTML) can go directly into CDATA without escaping; and extension namespaces (podcasting's <enclosure> tag was added this way) are a natural need in the RSS ecosystem. Switch to JSON Feed (and people have tried), and these problems come knocking again.

3. What an RSS Reader Does

Once you understand the feed format, understanding a reader is simple.

An RSS reader has four core steps, executed in a loop:

Fetch. For each subscribed feed URL, make an HTTP GET request. Key optimization: send If-None-Match (matching ETag) or If-Modified-Since (comparing Last-Modified). If the feed hasn't changed, the server returns 304 Not Modified and the reader skips it. Out of thousands of subscribed feeds in a reader instance, one polling round might return new content for only a few dozen.

Parse. Parse the XML to extract channel-level metadata and item lists. Handle both RSS 2.0 and Atom, plus wild feeds (missing guid, malformed pubDate, using <description> as <content>). A robust parser isn't about parsing the standard — it's about fault tolerance.

Deduplicate. Use guid (or Atom's id) to determine which entries are new versus already read. If the feed doesn't provide guid, fall back to link as the unique identifier. This is the most fragile part of RSS — no enforced unique identifier semantics, and different feed generators have wildly different guid strategies.

Display. New entries in reverse chronological order, marked read/unread.

That's the complete main loop of an RSS reader. If you've built one yourself, you know it's implementable in under 200 lines — fetch with http.Get, parse with encoding/xml, deduplicate with a map, display with HTML. The protocol is simple to this degree not by accident. It was genuinely designed to be simple.

Advanced features (full-text search, keyword filtering, cross-feed aggregation, folder classification) are all layered on top of this mainline. The core logic doesn't change.

4. Why RSS Lost

By 2013, Google Reader was the most iconic RSS reader. Then it shut down.

Google's stated reason was "declining usage." That may have been true, or not entirely. But Google Reader's closure was the result of a larger trend, not the cause.

The fundamental reason RSS was marginalized: the conflict between platform control and user control.

RSS gives readers complete control — you choose what to subscribe to, what to read, when to read it. No algorithmic interleaving, no recommendation interference, everything in reverse chronological order.

This is friendly to readers but unfavorable to platforms.

Social platforms like Facebook and Twitter built their business models on controlling traffic distribution. Algorithms decide what you see, in what order, with how many ads in between. RSS bypasses this entirely — you don't need to visit their website, log in, or even let them know who you are. The ad placements that advertisers pay for don't exist in RSS feeds. Without commercial incentive, not enough teams invest continuously in better readers and tools. This is a self-reinforcing spiral.

RSS had three structural problems of its own:

  • No user identity layer. RSS doesn't know who's reading. No personalization, no social — you can't see what friends recommended.
  • No feedback loop. Content creators only see an approximate subscriber count. No view counts, dwell time, or share metrics. Creators don't know who's reading.
  • Content is one-way. Publish → subscribe → read. No interaction, no comments.

But these aren't oversights of the protocol — they're natural consequences of RSS's design philosophy. RSS chose extreme simplicity; the cost is not solving identity, feedback, and interaction. This isn't a bug, it's a tradeoff. If you add OAuth login, read receipts, and a comment protocol to RSS, it becomes something else entirely.

RSS also had an often-overlooked barrier: usage friction. Subscribing to a feed requires manually finding the XML URL, pasting it into a reader, and managing a subscription list. Twitter does the opposite — register and go, algorithms fill the content for you. For an average user unfamiliar with URLs, this is quit-level complexity. This isn't a protocol problem, but it's likely a bigger demographic filtering factor than the business model.

Additionally, content creators themselves participated in RSS's decline. Some blogs, to pull readers back to their websites for ad revenue, provided only titles or summaries instead of full-text RSS. This wasn't forced by platforms — it was creators' own choice under commercial pressure.

5. It's Still Alive

Saying RSS is dead is inaccurate. It's just no longer in the mainstream.

Podcasting is RSS's most successful survival scenario. Every podcast you listen to on Apple Podcasts, Spotify, or any other client — the backend distribution protocol is RSS. Hosts put audio file links in the RSS feed's <enclosure> tag; clients fetch, download, and play. RSS's openness provides podcasting with a distribution mechanism where any client can equally access content. Of course, this isn't a sufficient condition for podcasting avoiding monopoly — but it's necessary infrastructure.

The independent blog community still uses RSS. Tech blogs, academic blogs, and independent authors who don't need platform traffic distribution use RSS to connect directly with readers, without depending on any platform's feature updates or algorithm changes.

Hacker News, Reddit, GitHub Releases, arXiv papers — these platforms still offer RSS feeds. You don't need to open each one's app or website daily; an RSS reader can aggregate updates from all these sources into one timeline.

A new generation of readers has emerged: Inoreader, Feedly, NewsBlur, Miniflux, NetNewsWire, Readwise Reader. Some commercial, some open source, none reaching Google Reader's scale — but that's a normal state. A decentralized protocol doesn't need a single unified client.

RSS won't make a comeback. It won't be the next trend, won't attract capital, won't appear on anyone's annual keyword list.

But it won't die either. As long as people write blogs, record podcasts, build static websites, and resist algorithmic recommendation walls — RSS will be there, quietly running. An XML file at a URL, an HTTP GET with If-None-Match, a 304 response or new entries.

A protocol did what it could. The rest isn't about technology.

References