What Is a GUID in a Podcast Feed

Ayush Sharma28th June, 2026
A row of podcast episode cards each tagged with a small fixed ID badge, one badge being swapped and triggering a duplicate copy of an episode

A GUID, globally unique identifier, is the permanent, one-of-a-kind ID attached to each episode inside your podcast's RSS feed. It's how Apple Podcasts, Spotify, and every other app tell one episode apart from the next and recognize the same episode across updates. You set it once when an episode publishes. After that, the single most important thing you can do with a GUID is leave it alone.

Every episode in your feed is an block, and inside that block sits a tag holding a string, often a long random code, sometimes the episode's URL. Apps don't track your episodes by title or by file name; both of those can change. They track them by GUID. That one stable string is the difference between editing an episode and accidentally publishing it twice.

What does a GUID look like in a feed?

A GUID is a single string of text inside the tag of an episode's . It can be a long alphanumeric code (like a1b2c3d4-...), the episode's permalink URL, or a value your host generates automatically. The RSS 2.0 specification only requires that the value be unique and stable; it doesn't dictate the format.

Most hosting platforms create the GUID for you the moment you hit publish, and most don't show it in the normal episode editor, you'd only see it if you opened the raw feed XML. That's by design. The value isn't meant to be human-friendly or memorable. It's a machine fingerprint. A title is for people; the GUID is for software.

Where the GUID sits inside a single feed item One RSS item block contains a title, a publish date, an enclosure with the audio file, and a GUID; the GUID is highlighted as the permanent identifier while title and file can change. One episode = one <item> in the feed <item> <title> Episode 12: Naming Things </title> can change <pubDate> Sat, 28 Jun 2026 </pubDate> can change <enclosure url="ep12.mp3"... /> can change <guid> a1b2c3d4-e5f6-7890-... </guid> never change </item> Format per the RSS 2.0 spec (rssboard.org). Diagram by QuickReel.
Where the GUID sits inside a single feed item. The title, date, and audio file can all change; the GUID is the one value meant to stay fixed.

What is a GUID used for?

The GUID is the identity check apps run on every episode, every time they refresh your feed. When an app re-reads your RSS feed, it compares the GUIDs it already has against the ones in the feed. A GUID it recognizes means "I've seen this episode, apply any edits to the existing entry." A GUID it has never seen means "this is new, add it and notify subscribers."

That comparison is what lets you fix things safely. You can correct a typo in a title, re-upload a cleaner audio file, swap the episode artwork, or rewrite the show notes, and because the GUID stayed the same, every app updates the existing episode in place. Subscribers don't get re-notified, your download count keeps accumulating against one episode, and the back catalog stays intact. Apple Podcasts treats the GUID as the value that must remain unchanged for the life of an episode, change it and Apple reads the result as a different episode.

The one rule: never change a published GUID

Here's the failure mode every podcast host warns about, and it's the whole reason this obscure tag matters. If you change the GUID of an already-published episode, apps treat it as a brand-new episode. The old one may stay in the feed with its original GUID, so listeners can end up seeing the same episode twice, once under the old ID, once under the new one, and the new copy re-notifies subscribers and re-pushes to the top of the feed as if it just dropped.

It gets worse than a cosmetic duplicate. Because download stats are tallied against the GUID, a changed GUID can split an episode's history into two records or orphan the accumulated numbers. Podnews describes the GUID as the value that "should never change" for exactly this reason, once it's out in the world, apps have memorized it. This is the single most common way hosts break their own feed, and it's almost always an accident: migrating to a new host that regenerates IDs, editing the feed by hand, or a plugin that rewrites the tag on save.

Same GUID updates the episode; a changed GUID creates a new one Top path: GUID unchanged, the app updates the existing episode in place with no re-notification. Bottom path: GUID changed, the app adds a second episode, re-notifies subscribers, and splits the stats. What the app does when you re-publish Edit + re-publish GUID unchanged Updates in place no re-notify · stats kept Edit + re-publish GUID changed Adds a 2nd episode re-notifies · splits stats Duplicate in the feed Behavior per Apple Podcasts requirements + RSS 2.0 spec. Diagram by QuickReel.
Same GUID updates the episode; a changed GUID creates a new one. The bottom path is the mistake that duplicates episodes and splits download stats.

The five-point GUID safety checklist

You almost never set a GUID by hand. You just avoid the actions that change one. Run this list whenever you touch your feed:

  1. Editing an existing episode? Change anything you want, title, audio, notes, but confirm the GUID stays identical. That's what makes it an edit and not a re-release.
  2. Migrating hosts? Use your new host's import-by-RSS flow, which carries the original GUIDs over. Don't let it generate fresh IDs, or every old episode re-publishes.
  3. Editing the XML by hand? Don't, unless you know exactly what you're doing, copy GUIDs verbatim and never regenerate them.
  4. Deleting and re-uploading an episode? That creates a new GUID. To replace a file, edit the existing episode instead so the GUID survives.
  5. Seeing a duplicate? A changed GUID is the first thing to check. Restore the original value if you still have it, or contact your host before publishing anything else.

How the GUID relates to the rest of the feed

The GUID is one of a handful of tags that make a feed item work, and it's the only one designed to be permanent. The episode's RSS feed wraps every episode in an ; inside that item, the enclosure tag points to the actual audio or video file, the title and date carry the human-readable info, and the GUID quietly holds the identity. The file the enclosure points to can be replaced; the GUID that names the episode should not be.

It's easy to confuse the GUID with ID3 tags, but they live in different places and do different jobs. ID3 tags are metadata baked inside the MP3 file itself, they travel with the audio if someone downloads it. The GUID lives in the feed, not the file, and exists only to identify the episode to apps. One describes the audio; the other names the episode. Both matter to clean podcast distribution, which is the umbrella over all of this, getting the same episode, correctly identified, to every app at once.

Frequently asked questions

Do I need to create a GUID myself? Almost never. Your hosting platform generates a unique GUID automatically when you publish an episode, and you typically won't see it in the standard editor. The only time you'd handle one directly is editing raw feed XML or migrating hosts, and in both cases the goal is to preserve the existing value, not invent a new one.

What happens if I change a published episode's GUID? Apps treat it as a brand-new episode. The new copy re-notifies subscribers and pushes to the top of the feed, the old version may linger as a duplicate, and download stats tied to the original GUID can be split or orphaned, since Apple Podcasts and other apps identify episodes by GUID. Restore the original value if you can.

Is the GUID the same as the episode URL? Not necessarily. A GUID can be the episode's permalink URL, and some feeds use that, but it can also be a random code unrelated to any web address. What matters per the RSS spec is that the value is unique and never changes, not whether it looks like a URL.

Can two episodes share a GUID? No. By definition a GUID is unique to one episode within your feed. Two items sharing a GUID confuses apps about which episode they're looking at and can cause one to be hidden or overwritten. If a host or migration ever produces a collision, treat it as a bug to fix before publishing.