Any RSS feed on any website.

Really Simple Syndication started life in 1999 as a Netscape feature for the doomed My Netscape portal. Dave Winer at UserLand picked up the spec the same year, simplified it, and shipped RSS 0.91 as a vendor-neutral way for any website to publish a machine-readable feed of its own content. The next decade saw a fork into the RSS 2.0 line, maintained by Winer and later donated to Harvard, and the parallel Atom Syndication Format effort, ratified by the IETF as RFC 4287 in 2005 to clean up ambiguities in the RSS spec. By 2008 the open web had two interoperable feed formats with overlapping element vocabularies, both readable by every major news reader, and both integrated into every major CMS. The format itself is almost trivially simple, which is why it has survived. An RSS or Atom feed is just an XML document listing recent items, each with a title, a link, a publication date, and optional metadata like author, category tags, full or excerpted content, and enclosure attachments for binary payloads like podcast audio. Any web server can produce one with no special infrastructure, any client can parse one with a hundred lines of code, and the contract has not meaningfully changed in twenty years. That stability is the whole point. When a publisher ships a redesign, switches CMS, or rebrands the site, the RSS endpoint typically keeps working because it sits behind a stable URL and emits the same simple XML. A widget that reads the feed today still reads it five years from now. No API key rotation, no OAuth refresh storms, no breaking changes from a vendor pivot.

When Google shut down Reader on July 1, 2013, the tech press wrote RSS obituaries. Most of them aged badly. What actually happened is that the consumer reading-app market consolidated around Feedly, Inoreader, and a long tail of indie clients like NetNewsWire and Reeder, while RSS quietly entrenched itself in three places where no algorithmic feed could replace it. First, podcasting. Apple Podcasts, Spotify, Overcast, Pocket Casts, and every other podcast app on the planet still discovers and ingests episodes via RSS feeds with `<enclosure>` tags pointing at MP3 files. The entire podcast economy, including over four billion episode downloads per month as of 2026, runs on RSS. Second, developer tooling. GitHub releases, npm package updates, PyPI new versions, Docker Hub image pushes, and Hacker News story streams all expose RSS feeds because RSS is the path of least resistance for a system that needs to publish a stream of timestamped events. Third, newsletter and aggregation infrastructure. Substack, Beehiiv, Ghost, and every major newsletter platform publishes an RSS feed of every issue, which is what makes cross-posting between platforms possible without an integration. Mailbrew, Stoop, and a long tail of newsletter-by-RSS services depend on this. The reason RSS survived in these niches and faded in mainstream consumer reading is the same reason: RSS is a producer-controlled, chronological, unfiltered stream. That model lost the consumer attention war to algorithmic feeds, but it stayed essential everywhere a system, an aggregator, or a power user wants the raw firehose without an algorithm in the middle. A modern website that embeds an RSS feed is opting into that producer-controlled model deliberately, which is increasingly the right call for content that should reach every reader the same way every time.

Both formats describe a list of items with a title, link, date, and optional content body. The differences come down to vocabulary precision and validation rigor. RSS 2.0 is the older spec, defined informally and frozen by Harvard's Berkman Center in 2003 with a deliberate stance that the format would not change further. Atom 1.0 was designed at the IETF specifically to fix RSS 2.0 ambiguities: dates use ISO 8601 instead of RFC 822, content has explicit type declarations like `text`, `html`, or `xhtml` so parsers know how to handle it, every entry is required to have a stable globally unique identifier, and the namespace model is consistent. In practice a publisher picks one format and sticks with it. WordPress emits both by default at `/feed/` (RSS 2.0) and `/feed/atom/` (Atom). Substack emits RSS 2.0. Ghost emits RSS 2.0. Hugo and Jekyll usually emit both. Major news outlets are split roughly evenly between the two. From the embedder's perspective, the format does not matter as long as the widget handles both transparently. Poper RSS Feed parses RSS 2.0, Atom 1.0, and JSON Feed 1.1 with the same code path, normalizes dates to ISO 8601, treats content as HTML by default with sanitization, and emits the same widget output regardless of which spec the source uses. JSON Feed 1.1, defined by Brent Simmons and Manton Reece in 2017, is a third option seen in indie blog stacks and some podcast directories. It carries the same item model in JSON instead of XML, which makes it easier to consume from JavaScript but harder to validate. A modern RSS widget should accept all three and let you forget the difference exists.

The algorithmic-feed era of social media optimized every consumer surface for engagement, which in practice meant ranking and filtering content by signals like predicted dwell time, comment velocity, and ad-click probability. The cost of that optimization is reach unpredictability. A creator who posts to Instagram, TikTok, or LinkedIn has no idea which percentage of their followers will see a given post, and the answer is generally lower every quarter. RSS makes the opposite trade. Every subscriber to a feed gets every item, in chronological order, on the publisher's schedule, with no ranking, filtering, or ad insertion in between. The price is that the publisher has to drive subscription themselves, since there is no algorithm to surface the feed to new readers. For a website embedding an RSS feed, that trade is exactly the right one. Visitors who land on your homepage and see a fresh content block are not a discovery audience. They already know who you are. They want to see what you shipped recently. An algorithmic feed in that surface would actively work against the goal, because it would hide items that the algorithm decided were less engaging, when the visitor specifically wants the chronological view. RSS is the only model that gives a website embedder direct control over what shows in the embed: every item from the source, in order, no surprises. Pair this with Poper's keyword and category filtering and you have a fully producer-controlled stream that lets you decide which items show without depending on a black-box ranker. In a year when algorithmic feeds are increasingly polluted with AI-generated slop and engagement-bait, the boring chronological RSS embed is quietly becoming a competitive advantage for sites that take their content seriously.

Four patterns cover most production deployments. First, blog mirror. A team publishes once on a primary blog (WordPress, Ghost, Substack, Medium, Hashnode) and embeds the RSS feed on a marketing site, partner portal, or help center. One source, many surfaces, zero copy-paste workflow. The marketing site stays fresh automatically and the source remains the single point of truth for the canonical URL, which protects SEO. Second, content hub or newsroom. Aggregate three or four feeds (your own blog, your podcast feed, a curated industry source, and your GitHub release feed) into one chronologically sorted block on a homepage to position your site as an always-fresh hub. Multi-feed merging is the killer feature here, since maintaining four separate widget instances would clutter the page and break the chronology. Third, podcast show-notes page. Point the widget at your podcast RSS feed and render episodes with inline audio players, episode duration, publication date, and show notes. The widget replaces both a separate audio player widget and a custom episode loop in your CMS. Fourth, product changelog or release-notes ticker. Most modern issue trackers and CI systems can publish a release feed (GitHub releases, npm publishes, Linear changelog, Productboard updates). Embed it on a product page or pricing page and your marketing surface stays in lockstep with what engineering shipped, with no manual cross-posting. In all four patterns the operational benefit is the same: the widget runs on a stable open standard, refreshes automatically, has no API key to rotate, and survives every redesign of the source. Set it up once and it does its job for years.