What Is an Enclosure Tag in a Podcast Feed

An enclosure tag is the single line of XML in a podcast's RSS feed that points an app to the actual audio file for an episode. It lives inside each and carries three attributes, url, length, and type, telling Apple Podcasts, Spotify, or any app where the file is and what format it is.

That one line is what separates a podcast feed from a plain blog feed. RSS itself was built to syndicate text. The enclosure element is the part that attaches a media file to an entry, and it's the reason a podcast can exist at all: without it, an app has a list of episode titles and descriptions but nothing to press play on.

What an enclosure tag looks like

Here's a real one, the way it sits inside a single episode's :

``xml ``

Three attributes, and all three are required by the spec, the RSS 2.0 specification calls each of them mandatory. Drop any one and most apps will refuse to play the episode, or skip it entirely.

• url, the direct, public web address of the media file. It has to be a real, downloadable link to the file itself (ending in .mp3, .m4a, or for video .mp4), not a link to a player page or a landing page.
• length, the file size in bytes, not seconds and not minutes. This trips up almost everyone. 38274560 here means roughly 38 MB. Apps use it to show a download size and to manage progressive downloads.
• type, the MIME type of the file, so the app knows how to handle it. audio/mpeg for MP3, audio/x-m4a for M4A/AAC, video/mp4 for a video episode.

How the enclosure tag actually works

When someone subscribes to your show, their app fetches your RSS feed, an XML file with one per episode. For each item, the app reads the enclosure tag, follows the url, and downloads or streams the file from that address. Your audio doesn't live inside Apple or Spotify. It lives wherever the url points (your host's storage), and every app pulls from that same link.

That's why the url matters more than any other field. If it 404s, every app breaks at once. If you change it after publishing, listeners with the old file cached may not re-download, and analytics can split. The enclosure URL is the single source of truth for the file, so hosts go to some length to keep it stable, that's also why download counts are measured at the host, by requests to that URL.

It also explains a common point of confusion. The enclosure tag is about delivery, pointing to the file. The metadata baked inside the file (episode title, artwork, artist) is handled separately by ID3 tags. And the permanent identity of the episode across feed changes is a different field again, the episode GUID. Three jobs, three mechanisms; the enclosure is only the one that delivers the bytes.

Common enclosure tag mistakes

If you write your feed by hand (most people use a host that generates it), these are the errors that break episodes:

• Putting seconds in length. It's bytes. A 1,800 in length tells the app the file is 1.8 KB, and it'll choke.
• Linking a player page, not the file. The url must end at the actual .mp3/.m4a/.mp4. A link to a webpage that contains a player won't play.
• A type that doesn't match the file. An M4A served as audio/mpeg can fail to play in stricter apps. Match the MIME type to the real format.
• An unstable or non-HTTPS url. Apps increasingly require HTTPS, and a URL that moves resets caches and muddies analytics.

You almost never edit this tag yourself. Hosting platforms (Buzzsprout, Libsyn, Transistor, Spotify for Creators) build the enclosure for you when you upload an episode. Knowing what it does still helps when you're distributing a podcast across apps, migrating hosts, or debugging an episode that won't appear.

Frequently asked questions

Is the enclosure tag required for a podcast? Yes. Without an enclosure tag inside an episode's , there's no media file attached, so it isn't a podcast episode, it's just a feed entry with text. Apple Podcasts and Spotify both need a valid enclosure to ingest and play an episode.

What's the difference between an enclosure tag and an ID3 tag? The enclosure tag lives in the RSS feed and points apps to the audio file. ID3 tags live inside the MP3 itself and hold metadata like title and cover art. One is delivery; the other is the file's own labeling. Apps mostly trust the feed over the ID3 data.

Can an enclosure tag point to a video file? Yes. Set type to video/mp4 and url to the video file, and the same mechanism delivers a video episode. The catch: most listening apps still treat RSS as an audio channel, so in practice video podcasts get watched on YouTube and platform-native feeds far more than through the enclosure. The enclosure stays the audio source of truth, and you can pull clips straight from a podcast's RSS audio without touching a video file.

Why is the file size in bytes instead of minutes? Because apps use it for download management and progress, not playback duration. Duration comes from a separate field (). The enclosure's length is a transfer detail: how many bytes the app should expect to pull from the url.