Podcast RSS with Transcripts: Add the Right Tag
podcastrsstranscriptionaccessibility

Podcast RSS with Transcripts: Add the Right Tag

BMMamane B. MoussaMay 26, 2026Updated July 2, 20269 min read

Summarize this article with:

The Tag That Matters

SRT and VTT exports are what the transcript tag points to
SRT and VTT exports are what the transcript tag points to

The podcast:transcript element lets podcast apps display your transcript without scraping or guessing. You host the file, add one tag inside your RSS feed's item block, and any client that supports the Podcasting 2.0 namespace can pick it up. This post covers the exact spec, the app support picture as of mid-2026, which format to use, and the common mistakes that silently break display.

What the Spec Actually Looks Like

The element lives in the Podcasting 2.0 namespace, maintained by the Podcast Index project. Your feed's channel element needs the namespace declaration, and each item gets its own transcript tag.

<rss version="2.0" xmlns:podcast="https://podcastindex.org/namespace/1.0">
  <channel>
    <item>
      <title>Episode 42: The Future of Live Audio</title>
      <enclosure url="https://example.com/episodes/42.mp3" length="..." type="audio/mpeg"/>
      <podcast:transcript
        url="https://example.com/transcripts/42.vtt"
        type="text/vtt"
        language="en"/>
    </item>
  </channel>
</rss>

The four attributes:

  • url: Direct link to the transcript file. Must be HTTPS, no authentication.
  • type: MIME type. The spec accepts text/vtt, application/x-subrip (SRT), text/html, text/plain, and application/json (the PodcastIndex JSON format).
  • language: BCP 47 code such as en or fr. Optional when your channel-level language attribute already covers it.
  • rel: Optional. Set to rel="captions" if the file is a live-captions track rather than a full transcript.

You can include multiple podcast:transcript tags per episode, one per format or language.

Who Actually Reads Your RSS Tag

This is where the picture gets more nuanced than most guides admit. There is an important distinction between apps that read your RSS-linked file and apps that generate their own transcript independently.

AppReads your RSS transcript tagNotes
Apple PodcastsYes, as overrideAuto-generates by default; your VTT or SRT file replaces it if present. HTTPS required.
Pocket CastsYes, all usersVTT, SRT, JSON, HTML all supported. Plus/Patron subscribers also get auto-generated fallback.
CastroYesAdded Feb 2025. Supports all four Podcast Namespace formats. No auto-generation.
Podcast AddictYesSRT, x-subrip, JSON, and HTML supported.
Player FMYesDisplays RSS-linked transcripts with a transcript icon.
FountainYesStrong support, including on-demand premium transcripts.
GoodpodsYesTranscripts displayed from RSS.
AntennaPodYesOpen-source Android client with full namespace support.
MetacastYesTranscript-first player; prioritizes creator-provided content.
OvercastUnconfirmedFull transcript view added April 2026 (version 2026.04). Sources describe emphasis on on-device auto-generation for iOS 26; RSS tag ingestion not confirmed in official docs.
SpotifyNoGenerates its own transcripts for select shows. Accepts VTT/SRT uploads (5 MB max) for creators to distribute outward via RSS to other apps, not the reverse.
Amazon MusicNoAuto-generates for select large shows only.
CastroYesSupports all four formats; no dynamic ad sync yet.

My take: the framing of "three of the five biggest clients" undersells what is actually live. The real gap is between the major streaming platforms (Spotify, Amazon) and the podcast-native clients. Every serious podcast client outside the streaming giants either already reads your transcript tag or has announced it.

VTT vs SRT vs JSON: Which to Publish

The spec accepts five MIME types, but three formats do the real work.

VTT (text/vtt) is the strongest default. Native to web browsers, supported by Apple Podcasts, Pocket Casts, Castro, AntennaPod, and most other namespace-aware clients. It natively supports speaker labels via cue identifiers, which matters for interview and co-hosted shows. If you can only generate one file, make it VTT.

SRT (application/x-subrip) is older and simpler. No native speaker labels (you put them inline in the cue text), but near-universal recognition. Use SRT if you also upload the same file as YouTube subtitles, or if a downstream tool requires it. Note that the correct MIME type for the RSS tag is application/x-subrip, not application/srt.

JSON (application/json) follows the PodcastIndex JSON transcript schema with a version, segments array, and per-segment speaker, startTime, endTime, and body fields. It enables word-level and sentence-level timing, which apps can use for highlighted playback. Spotify does not pick this up from your RSS feed, but clients like Pocket Casts and Fountain do use it for smooth scroll playback.

Most shows doing this well publish VTT for the RSS tag and keep JSON available on the episode page for richer in-browser experiences. Both files are small, well under a few hundred kilobytes per hour of audio, so storage cost is not a factor. For generating either format from your edited audio, the audio-to-text tool exports both, and the subtitle generator lets you convert between them.

Generating the Transcript File

Upload the final edited audio, not the raw recording. AI transcription tools handle post-edited audio much better: music stings and crosstalk from unedited takes introduce errors that end up in the published file.

A typical workflow for a 45-minute episode:

  1. Upload the final MP3 to a transcription tool with speaker diarization enabled.
  2. Export as VTT. If your host or workflow supports JSON, export that too.
  3. Spot-check the first and last two minutes, plus any proper nouns, technical terms, or guest names.
  4. Fix speaker labels if the diarizer assigned generic "Speaker 1" labels.
  5. Upload both files to your hosting location.
  6. Add the podcast:transcript tag to the RSS item.

The active work per episode is about ten minutes after the audio is final. For episodes where you also generate podcast show notes, the transcript feeds that process directly.

If you need transcripts for dozens of back-catalog episodes at once, ConvertAudioToText supports batch URL submission, so you are not uploading files one by one.

Where to Host the File

The transcript URL must be publicly accessible over HTTPS with no login. Your options, roughly in order of convenience:

Your podcast host. Buzzsprout, Transistor, Captivate, RSS.com, and Fireside all accept transcript uploads per episode and write the RSS tag for you automatically. If your host supports this, use it: they handle MIME types, CORS, and tag injection.

Your episode page or CMS. If you publish episode pages on your own site, drop the VTT file in the same directory and link it from the feed. This also makes it crawlable by search engines.

Object storage. Cloudflare R2, AWS S3, and Backblaze B2 serve static files for fractions of a cent per gigabyte. Set a Content-Type: text/vtt header explicitly; most CDNs default unknown extensions to application/octet-stream, which breaks app rendering.

GitHub Pages. Free and sufficient for small shows. Add a _headers file to set the correct content type.

CORS headers are not required since apps fetch the file directly, not from a browser cross-origin context. But if you configure CORS, Access-Control-Allow-Origin: * is appropriate for transcript files.

Mistakes That Break Display Silently

These fail with no error in the podcast client, making them hard to diagnose:

HTTP instead of HTTPS. Apple Podcasts will silently skip any transcript URL that does not use TLS. Start with HTTPS and do not redirect.

Wrong MIME type. The most common one. Set Content-Type: text/vtt at the server or CDN layer, not just in the RSS attribute. Some clients trust the Content-Type header over the declared type.

Wrong SRT MIME type in the tag. The spec value is application/x-subrip. Using application/srt (a common but unofficial variant) causes some clients to skip the file.

Language attribute mismatch. If your channel says en but the transcript tag says en-US, some apps refuse to display. Match the format your feed uses, or omit the attribute entirely when it would duplicate the channel-level language.

Empty cues. Auto-generated transcripts often emit blank cues at silences. Strip them before publishing; some clients error silently on malformed cue blocks.

Missing speaker labels for multi-speaker shows. Apple shows a generic fallback when labels are absent. Relabel in post before publishing. For the mechanics of how diarization works and what to expect from automated labeling, see speaker diarization explained.

Publishing in Multiple Languages

The podcast:transcript element can appear multiple times per item, one per language. Point each to the correct file with the matching language attribute:

<podcast:transcript
  url="https://example.com/transcripts/42-en.vtt"
  type="text/vtt"
  language="en"/>
<podcast:transcript
  url="https://example.com/transcripts/42-fr.vtt"
  type="text/vtt"
  language="fr"/>

Apple Podcasts supports transcripts in English, Danish, Dutch, Finnish, French, German, Italian, Norwegian, Portuguese, Spanish, and Swedish. Episodes over 10 hours are not transcribed by Apple, and music lyrics are excluded from Apple's rendering.

Common Questions

Does Spotify read the podcast:transcript tag from my RSS feed?

No, not directly. Spotify generates its own transcripts for select shows and displays them in the Now Playing view and on episode pages. What Spotify does support is exporting your transcript outward via RSS to other platforms: if you upload a VTT or SRT file in Spotify for Creators (Settings, then Transcripts), Spotify can distribute it in your RSS feed for other apps to read. The flow is Spotify-to-others, not others-to-Spotify.

Which file format should I publish in my RSS feed?

VTT is the safest single choice. It is supported by Apple Podcasts (for custom transcript override), Pocket Casts, Castro, AntennaPod, Podcast Addict, and other namespace-aware clients. SRT is a close second. JSON adds value for apps that can highlight words during playback, but it works best as a second file on your episode page rather than as your sole RSS-linked format.

What MIME type do I use for SRT files?

The Podcasting 2.0 spec uses application/x-subrip for SRT. Using application/srt (a common informal variant) may cause some clients to skip the file. Set your CDN or server to serve the file with Content-Type: application/x-subrip and match that in the type attribute of your RSS tag.

Do I need the transcript on my episode page too, or is the RSS tag enough?

The RSS tag handles in-app display. Publishing the transcript text on your episode page is a separate, worthwhile step: audio is not indexable by search engines, transcript text is. The podcast accessibility transcripts post covers the SEO and accessibility case for on-page transcripts. You should do both: the RSS tag for listeners in apps, the page for discoverability and screen-reader access.

Sources

Try transcription free

Convert any audio or video to clean, unwatermarked text — speaker labels, timestamps, and AI summaries included. First 30 minutes free, no account.

Related Articles