Tutorials Audio

The Podcast Namespace: Transcripts and Chapters in Your RSS Feed

By Infinite Creation · Intermediate · ~11 min

Overview

A podcast feed is an RSS file, and RSS was designed for text articles rather than for audio. Everything podcasting needs beyond a headline and a file has been bolted on since. The podcast namespace is the current attempt at doing that properly: a shared set of tags, maintained in the open, that carry transcripts, chapters, contributor credits, funding links and more. The two that change the most for the least effort are transcripts and chapters. Both make an episode searchable and usable in ways audio alone cannot be, and both are a single line in the feed once the file exists.

What You Need

Control of your RSS feed, or a host that supports the podcast namespace tags
A transcript per episode. A corrected machine transcript is fine, an uncorrected one is not
Somewhere to host the transcript and chapter files, which can be the same place as the audio
A feed validator, so you can see what you actually published rather than what you intended

Steps

Declare the namespace once, at the top

The tags live in their own XML namespace so they cannot collide with anything else in the feed. Add the declaration to the opening rss element, using the prefix podcast against the namespace URL at podcastindex.org. Every tag below then carries that prefix. Most hosts that support these tags do this for you, and if yours does not, this is the line to add.

Add a transcript to each episode

The transcript tag takes a url and a type, and both are required. Accepted types are plain text, HTML, WebVTT, JSON and SubRip. Two optional attributes matter: language, which lets you offer the same episode in more than one, and rel set to captions, which marks the file as timed captions rather than a plain reading transcript. WebVTT with rel captions is the most useful single choice, because a player can follow along with it.

Write chapters as a separate file

The chapters tag also takes a url and a type, and the preferred type is a JSON chapters file. Keeping chapters outside the audio has a practical consequence worth understanding: they can be corrected after publication without re-encoding and re-uploading the episode. A chapter list embedded in the file itself cannot be.

Understand what apps actually do with them

Support is uneven and that is the honest position. Some apps show a scrolling transcript, some offer search within an episode, some display chapter art and titles, and some ignore all of it. Nothing breaks in an app that does not support a tag, because unknown namespaced elements are skipped. That asymmetry is why adding them is worth it: the cost of being early is close to zero.

Correct the transcript before you publish it

An automatic transcript is a draft. Names, technical terms and speaker changes are where it fails, and those are exactly the words somebody searching for your episode will type. If you publish only one corrected artefact per episode, make it the transcript, because it is the thing that makes the audio findable.

Validate the feed rather than trusting it

Publish, then read the feed back and confirm the tags are present, the URLs resolve, and the types match the files. A transcript tag pointing at a missing file is worse than no tag, because an app will try to load it. Check it once after the first episode and again after any change of host.

Pro Tips

Serve transcript and chapter files with the right content type. A WebVTT file served as plain text will be refused by some players.
Keep the transcript at a stable URL. Feeds are cached and re-read for years.
If your host does not support these tags, that is a reason to ask them, not a reason to skip the transcript. Publish it on the episode page regardless.

Knowledge Base

The Longer Answer

Two questions come up more than any other: whether these tags are safe to add, and what to do when your host controls the feed and you do not.

Why podcasting needed a namespace at all

RSS was designed to syndicate text articles, and podcasting arrived by attaching an audio file to an item designed to carry a headline and a paragraph. Everything since has been an extension, and for years the only widely supported one belonged to a single company, which meant the feature set of podcasting was decided by whoever maintained it. A namespace changes that arrangement rather than the file format. It gives a shared, openly maintained set of tags a prefix of their own, so anybody can propose one, no tag can collide with an existing extension, and a reader that does not recognise a tag skips it instead of failing. That last property is the whole reason adoption is low risk.

What to do when your host owns the feed

Most shows do not hand-write their RSS, which means the practical question is not which tag to use but whether your host emits it. Three things are worth doing in order. Check what your feed actually contains rather than what the dashboard implies, by reading the published XML. If the tags are absent, ask the host directly, because feature requests from paying customers are how host support has expanded. And publish the corrected transcript on the episode page regardless, because the accessibility and search value of a transcript does not depend on the feed carrying a pointer to it. A host that cannot emit the tags is a reason to keep asking, not a reason to skip the transcript.

Where This Fits

Transcripts and chapters extend the feed, and Best Podcast Setup for Beginners covers the show that feed carries.

FAQ

Q: Do I need a transcript for every episode?
A: For accessibility and for search, yes. A corrected transcript is the single most useful artefact you can attach to an episode, because it makes spoken content findable and usable by people who will not or cannot listen.

Q: Will these tags break my feed in apps that do not support them?
A: No. They are namespaced, so an application that does not recognise them ignores them. That is what makes adopting them low risk.

Q: Which transcript format should I use?
A: WebVTT with the rel attribute set to captions, if you have to choose one. It carries timings, so a player can follow along, and it is widely understood because it came from video captioning.

Q: Can I fix chapters after publishing?
A: Yes, provided they are in a separate chapters file rather than embedded in the audio. That is the main practical argument for the tag.

Vocabulary

Podcast namespace An open set of RSS tags for podcasting, maintained in public by Podcastindex-org, covering transcripts, chapters, contributors, funding and more. Using a namespace means the tags cannot collide with other extensions already present in a feed.

XML namespace A prefix declared once at the top of a document that scopes every tag using it, so that two specifications can both define a tag called transcript without ambiguity. Readers that do not recognise a namespace skip its elements rather than failing.

WebVTT A timed text format originally built for video captions, carrying text with start and end times. In a podcast feed it lets a player highlight the transcript in step with the audio rather than showing a wall of text.

JSON chapters A separate file listing chapter start times, titles and optionally images and links. Because it sits outside the audio file, chapters can be corrected after an episode is published without re-encoding anything.

Sources

The specification was read directly, and the attribute lists below come from it rather than from a summary of it. Checked 26 August 2026.

Podcastindex-org, The Podcast Namespace, version 1.0. The specification itself, maintained in the open. It gives the namespace URL as podcastindex.org/namespace/1.0 and the suggested prefix as podcast, and states that all attributes are required unless a tag's own documentation marks them optional.
Podcast namespace, transcript tag. Confirms url and type as required, language and rel as optional, and lists the accepted mime types as text/plain, text/html, text/vtt, application/json and application/x-subrip. It also defines rel="captions" as marking the file as closed captions.
Podcast namespace, chapters tag. Confirms url and type as required and gives application/json+chapters as the preferred type. It states the reason for keeping chapters in a separate file: they can be edited after publishing, which an embedded chapter list cannot.