Podcast RSS Explained: From `<enclosure>` to Podcasting 2.0 and Why Open Distribution Still Matters | Mr. XYZ Downloader

What is podcast RSS, and why do some feeds use itunes:, content:encoded, and podcast:? This guide explains podcast RSS history, feed format differences, and why RSS still matters for open podcast distribution.

xyzdownloader started as a side project in the second half of last year. The original goal was simple: make it easier for me and my family to listen to podcasts, and do a bit of podcast information and knowledge management along the way.

Interestingly, this project has picked up more and more users this year. Thank you.

As I kept responding to user feedback, improving the product, and adding new features, I started seriously digging into the technical standards behind podcast RSS. The more I read, the more interesting it became. Behind those cold-looking XML tags lies a long history of standards wars, commercial power struggles, and plenty of geek-world drama.

This article is my attempt to reorganize that main thread into a faster-reading blog version.

If you want the full long-form version, you can jump here:

👉 “RSS Schisms, Apple Control, and Spotify Land Grabs: The Never-Ending Standards War Behind Podcasting”

Unauthorized republication is not allowed. If you want to republish, quote, or discuss collaboration, please contact the author through the author's WeChat public account or X account.

In today's world of algorithmic recommendations, platform distribution, app ecosystems, and content walled gardens, it is almost surprising that podcasting has still not been fully reinvented by a single platform. When you subscribe in Apple Podcasts, XiaoYuZhou, Pocket Casts, or even Spotify, what sits underneath is often not a private platform protocol at all, but a publicly accessible XML feed.

That is exactly why podcasting is so different from short video, social feeds, or music streaming. At the infrastructure level, it is not "the platform owns your distribution." It is "the creator owns the feed, and platforms read from it."

That is why RSS is still worth understanding, even now.

Podcast RSS Is Not a Relic. It Is the Foundation of Open Distribution

Most people first encounter podcast RSS when they try to parse an episode link, use a download tool, or open a real feed file.

And then the questions come immediately:

Why are some feeds very clean, with only basic tags?
Why are others full of itunes:, atom:, content:, and dc:?
Why do newer feeds now include podcast:transcript, podcast:chapters, and podcast:value?

The answer:

Podcast RSS has never been a single standard settled once and for all. It is an ecosystem that kept growing through long-term compatibility work, platform negotiation, and community-driven innovation.

It is like an old tree. The trunk appeared early, but new branches kept growing.

Why Was Podcasting Built on RSS?

Podcasting did not begin with apps. It began with distribution.

What made it possible was that around 2000, RSS gained one crucial capability: attaching media files to a subscription stream.

That key tag looked like this:

XML

<enclosure url="http://www.example.com/episode.mp3"
           length="12345678"
           type="audio/mpeg" />

<enclosure> looks ordinary, but it did one decisive thing:

It turned "article updates" into "automatic media distribution."

RSS was no longer just a way to send blog headlines and summaries. It could now hand over audio files too. Later, Adam Curry used scripts to download those files automatically and sync them to an iPod. That was the moment podcasting stopped being "audio on a webpage" and became a subscribable, auto-updating, offline-friendly medium.

In short: without <enclosure>, there would be no modern podcasting.

Why Do Different Podcasts Have Completely Different RSS Feeds?

Because podcast RSS is not just "one format." It is:

core RSS 2.0 + namespace extensions.

Core RSS handles the most essential things:

show title
show description
publication date
audio file URL
unique identifier

But once podcasting started scaling, that was not enough. Platforms quickly realized they also needed:

cover art
categories
host metadata
explicit-content flags
season and episode numbering
richer show notes
chapters
transcripts
monetization hooks

That is when the extensions began.

The 4 Namespaces You See Most Often

If you open a few real podcast feeds, the most common ones will usually be these:

1. `itunes:`: Apple's De Facto Standard

This is probably the most influential family of tags in podcasting.

It solves the problem of how a show should display correctly in mainstream podcast clients, for example:

<itunes:image>
<itunes:author>
<itunes:category>
<itunes:duration>
<itunes:episode>
<itunes:season>

Technically, RSS is open. But in practice, for a long time, Apple Podcasts compatibility requirements were almost the industry standard.

That created a strange but very real situation:

the foundation was open
the display rules were heavily shaped by Apple

That is one reason Podcasting 2.0 later re-emerged with so much force.

2. `content:encoded`: Making Show Notes Actually Readable

The basic <description> tag is often not enough.

If you want to include:

linked references
timestamp lists
rich-text intros
images and extra notes

then you usually need content:encoded.

The easiest way to think about it is:

it lets RSS carry full HTML content, not just a summary.

That is why some traditional media organizations and professional hosting platforms have much richer feed descriptions.

3. `atom:link`: Telling Clients Who the Feed Really Is

Many modern feeds include a line like this:

XML

<atom:link href="https://feeds.example.com/podcast.xml"
           rel="self"
           type="application/rss+xml" />

Its role is simple, but important:

it declares the canonical identity of the feed itself.

That matters during hosting migrations, domain changes, or feed upgrades, because clients can more reliably understand which subscription source they are actually following.

4. `podcast:`: The New Extension Layer of Podcasting 2.0

If itunes: represents the power structure of the old podcast world, then podcast: feels more like the response from a new generation of open-podcast builders.

These tags try to add capabilities that were missing for a long time, such as:

<podcast:transcript>: transcripts
<podcast:chapters>: chapters
<podcast:person>: participant metadata
<podcast:soundbite>: highlights
<podcast:value>: Value4Value tipping

The logic here is not "replace RSS."

It is:

keep old subscriptions working, while letting RSS grow new capabilities.

That is one of the biggest differences between podcasting and more closed platforms. It does not upgrade by forcing everyone onto one entirely new protocol. It survives through backward compatibility and gradual extension.

Why Do Different Platforms Feel Like Different "Schools"?

If you roughly classify real-world podcast feeds, you can usually see three common styles.

Traditional Media Style

Think of organizations like NPR. Common traits include:

fewer namespaces
cleaner structure
stronger standards discipline
well-structured show notes

The advantage is stability, clarity, and easier parsing.

Hosting Platform Style

Platforms like Simplecast, Buzzsprout, and Captivate are usually more comprehensive:

itunes is there
atom is added
content is supported
newer tags are followed when possible

Because these platforms serve many creators, their goal is not purity. Their goal is broad compatibility across clients.

Independent Geek Style

Technical podcasts, independent sites, and more creator-friendly hosts are often more willing to experiment with:

richer HTML show notes
fuller metadata
faster Podcasting 2.0 adoption

These feeds are often the best place to observe where open podcast standards may be heading next.

Why Does RSS Still Matter Today?

Because RSS does not just decide how a file is written. It decides who controls distribution.

If podcasting becomes fully platform-native content, what happens?

creators cannot freely migrate subscription relationships
listeners cannot freely choose clients
platforms can unilaterally control recommendation, distribution, and disappearance
whether a show continues to exist depends on platform policy, not whether the creator still has a reachable feed

RSS represents a different order:

creators can own their own feed
listeners can choose their own player
clients can replace one another
platforms are readers, not the only gate

That is why RSS still carries special weight in podcasting.

It may not be fashionable, but it is an anti-fragile distribution structure.

If You Are a Listener, Why Should You Care?

Quite a lot, actually.

1. You Understand Why Some Shows Can Be Downloaded and Others Cannot

Whether a show exposes a real RSS feed, whether it contains a standard enclosure, and whether it is locked inside a closed platform all directly affect downloading and migration.

2. You Understand Why Not All Podcast Links Are Equally Parsable

Some platforms are basically webpage wrappers around RSS.

Others are already moving toward closed, app-native content systems.

On the surface, both look like episode pages. Underneath, they are not the same thing at all.

3. You Can Better Judge Whether a Platform Actually Respects Creators and Users

Does it expose RSS? Does it support migration? Does it keep compatibility with common tags? Does it adopt open standards? Those are not tiny implementation details. They reflect the platform's values.

If You Are a Creator, RSS Matters Even More

Many creators do not pay much attention to their feed early on. They just hand it over to a hosting platform and let it "take care of itself."

But once you start treating your show as a real content asset, RSS becomes one of the most important things to understand underneath it.

At minimum, you should know:

what your feed URL is
which namespaces your host supports
whether feed migration is supported
whether transcript / chapters / person / value extensions are supported
whether your metadata is complete

Because in the long run, the episodes are the asset, and the feed is the distribution pipeline for that asset.

Many platform tools look like they are "helping you distribute." But what actually determines your long-term control is whether you can take that distribution relationship with you.

A More Practical Standard: RSS Is Not Nostalgia, It Defines Capability Boundaries

Many people treat RSS as an old-web sentimental artifact. In podcasting, it is much more practical than that.

It determines:

whether multiple clients can read your show
whether it can be searched, migrated, and backed up
whether your subscription relationships survive platform policy changes
whether your content can move from "a platform page" into "a data source you actually control"

So the real question is never "Is RSS still alive?"

It is:

As long as podcasting wants to preserve open distribution, RSS, or some equivalent open protocol, will continue to matter.

Finally: If You Want the Full Version

This blog version is more of a framework-building guide for quick reading.

If you want the longer deep-dive version, including:

the full history from Netscape to Dave Winer
the split between RSS 1.0, RSS 2.0, and Atom
how Apple's itunes: namespace became the de facto standard
why Spotify's walled-garden strategy triggered backlash
what Podcasting 2.0 actually added

you can continue here: