Podcast transcript format: the conventions that actually matter

Ask ten podcasters how to format a transcript and you get style guides written for court reporting, a Reddit thread, and a university accessibility page. The conventions are real, but they are scattered, and most of them were written for transcription agencies rather than for a show trying to publish an episode page.

If you’re deciding on a podcast transcript format, four choices matter most: verbatim vs clean read, speaker labels, timestamps, and file type.

This is the short version of what actually matters, with the output for each decision so you can see the difference rather than read about it.

Podcast transcript format: the 4 decisions that matter

Everything else is detail. A transcript's format is settled by four choices: how faithful the words are, how speakers are marked, whether timing is present, and which file the whole thing lives in.

Before the details, here is the fast version.

If you want the default answer for most shows, it is this:

1. Use clean read.
2. Add speaker names.
3. Add timestamps only where navigation helps on public pages.
4. Keep SRT, WebVTT, or JSON separately for machines and players.

That split matters for usability and accessibility. A transcript that reads well helps people follow along, including deaf and hard-of-hearing users, while caption files and segment JSON solve different technical problems. The W3C Web Accessibility Initiative is a good reference on why transcripts and captions serve related but different needs.

1. Verbatim or clean read

Of the four, this one changes the reading experience most, and it is the one people skip.

Clean read removes filler words, stutters, false starts and repeated words. The meaning and the voice survive, the noise does not. Use it for a published episode page. It is what most listeners assume a transcript is.

Full verbatim keeps everything: every um, every self-interruption, every repetition. It exists because sometimes how a thing was said is the data. Research interviews, legal work, and qualitative analysis all need it. Almost no podcast does.

The same thirty seconds, both ways:

FULL VERBATIM

Sarah: So, um, the the thing that surprised me, I guess, was that
nobody, like, nobody actually asked for it? We just, we assumed.

Marcus: [laughs] Right, yeah. That happens a lot.

Pick one and hold it for the whole document. A transcript that starts verbatim and drifts into clean read reads like two people made it, because usually two people did.

What to do with non-speech sound

Square brackets, sparingly: [laughs], [crosstalk], [inaudible 14:32]. Mark an inaudible passage with its timestamp so someone can go and check it. Do not narrate the music.

2. Speaker attribution

Use names, not initials

"S:" and "M:" save four characters and cost the reader real effort. Full name on first appearance, short form after.

One format, consistently

Name followed by a colon, or the name on its own line above the paragraph. Both are fine. Switching between them is not.

Mark the change of speaker with a paragraph break

A new speaker always starts a new paragraph, even for a one-word answer. Nothing else does as much for scannability, and nothing is more commonly missing from machine output.

If you need a definitional reference for that term, speaker diarization is the separate task of figuring out who spoke when.

3. Timestamps, and where they belong

Timestamps are navigation, not decoration. Three sensible levels:

Every few paragraphs, for a readable page

Enough to jump into the audio at the right moment, rare enough to stay out of the way. Topic changes are the natural place.

Per line, for captions

Caption formats need timing on every cue. That is what they are for, and it is why a caption file makes a poor reading experience.

Per segment, for software

When a program is the consumer, keep the timing structured rather than written into the prose.

Keep the timestamped version even if you publish the prose one. Going from timestamps to readable text is a formatting pass. Going the other way usually means transcribing again.

4. The file format

Four formats cover essentially every use, and the same excerpt looks like this in each:

[00:14] Sarah: The thing that surprised me was that nobody actually
asked for it. We just assumed.

[00:21] Marcus: Right. That happens a lot.

Which podcast transcript format to use

Plain text or HTML for the episode page a human reads.

SRT where a video player or an editing tool expects captions. If you want a stable reference for the format, the Library of Congress format description for SubRip (SRT) is a useful overview.

WebVTT where the web platform or a podcast host wants a caption file. WebVTT is similar to SRT, but it has its own syntax, timing format, and support for metadata and styling in web contexts. The canonical reference is the W3C WebVTT specification.

JSON with segments whenever software is the consumer, because parsing timestamps back out of prose is work nobody should repeat.

Best podcast transcript format for websites, captions, and apps

If you do not want a framework and just want the recommendation, here it is.

For your website

Use clean read HTML or plain text, speaker names in bold, paragraph breaks at every speaker change, and timestamps only at topic changes or every few paragraphs. That is the best podcast transcript format for readers.

For caption files

Use SRT or WebVTT. These are for players, hosting workflows, and timed display, not for comfortable reading.

For software and internal workflows

Use JSON segments with start times and durations. If speaker labels exist, keep them structured there too.

What the platforms expect

Apple Podcasts

Apple has rolled out transcript features in its ecosystem and displays transcripts in Apple Podcasts for supported content. Apple’s own documentation is the place to check current behavior, because rollout details and supported workflows can change over time. See Apple Podcasts transcript support and Apple Podcasts for Creators.

The practical point is simpler than the platform details: in the normal case, you are not formatting a prose transcript page for Apple Podcasts itself. If a host supports supplying a transcript or caption asset, treat that as a timed file workflow rather than assuming your website HTML is what the platform wants.

Spotify

Spotify shows transcripts inside its apps for some shows, but it does not provide a general public export workflow for creators who want transcript text for their own site. For current feature details, check Spotify for Creators.

If you want the text of a Spotify episode for your own site, you are transcribing the audio, not exporting from Spotify. Our Spotify transcript generator resolves an episode link back to the show's public feed and transcribes the real audio file, which is the route that works from outside.

Your own site

The one you control, and the one that earns anything. Publish the transcript as a real page with the episode title, a short summary, headings at topic changes, and speaker names in bold. Dumped as a raw wall of text it technically contains the words, and reads as thin content to both a person and a search engine.

This is also where transcript formatting does the most accessibility work. A readable transcript gives people a way to follow and navigate spoken content without relying on audio alone, which is why structure matters, not just word accuracy.

Getting the transcript in the first place

If you are formatting by hand from scratch, stop and get a machine draft first. Editing a rough transcript into clean read is an hour. Typing one from audio is most of a day.

Got one episode to do? Paste the link into TranscriptFetch's free podcast transcript generator. For a back catalogue, the podcast transcript API returns the same text and timestamped segments from a Spotify link, an Apple Podcasts link, or an RSS feed, one credit per episode regardless of length.

# pip install transcriptfetch-sdk
from transcriptfetch import TranscriptFetch

# api_key falls back to the TRANSCRIPTFETCH_API_KEY env var
tf = TranscriptFetch()

result = tf.transcripts.video("https://open.spotify.com/episode/...")
for s in result.segments:
    print(f"[{int(s.start // 60):02d}:{int(s.start % 60):02d}] {s.text}")

Segments in, formatting pass out. Want to see each style rendered in full before you choose? The companion piece, podcast transcript examples, shows the same episode excerpt in every format side by side.

The mistakes that make a transcript unusable

A wall with no paragraph breaks

Machine output often arrives as one continuous block. Break at speaker changes and at topic changes, always.

Timestamps on every line of a reading page

Correct for captions, exhausting for prose.

Inconsistent speaker labels

"Sarah:", then "SARAH", then "S:". Pick one.

Publishing raw ASR output

It will have no punctuation in places, no capitalisation of names, and no paragraphs. Ten minutes of editing is the difference between a page worth publishing and one that damages the impression of the show.

FAQ

What format should a podcast transcript be in?

For a website, plain text or HTML with speaker names and paragraph breaks. For Apple Podcasts, check the current Apple workflow rather than assuming a public upload field exists for prose transcripts. For an app or a search index, JSON with timestamped segments. Publish the readable version to the public and keep the timestamped one for the machine, since converting from timestamps to prose is easy and the reverse is not.

Should a podcast transcript be verbatim or clean read?

Clean read for almost every podcast. It removes filler words, stutters and false starts while keeping the meaning and voice, and it is what people actually want to read. Full verbatim, which keeps every um and repetition, matters for research, legal work and qualitative analysis, where how something was said is part of the data.

How should speakers be labelled in a transcript?

Name on its own line or followed by a colon, consistent for the whole document, with the full name on first use and a short form afterwards. Do not switch between formats, and do not use initials alone: a reader scanning for one person's answers needs a label they can spot without decoding it.

Do podcast transcripts need timestamps?

Not for reading. Timestamps help when the transcript is a navigation aid, so every few paragraphs or at topic changes is plenty for a show page. Per-line timestamps belong in caption files, SRT and WebVTT, and in JSON for software, where the timing is the point rather than a distraction.

Does a transcript help podcast SEO?

It gives search engines text where there was only audio, which is the difference between being indexable and being invisible. That is a real benefit and it is often overstated: a transcript dumped on a page with no headings or structure is thin content. Publish it as a readable page with an episode summary and headings, not as a wall of raw output.