Podcast transcript examples: one episode, six formats

Search for a podcast transcript example and most of what comes back is podcast scripts: templates for what to say before you record. Useful, and not the same thing.

This page is the other thing. One excerpt from a two-person interview episode, sixty seconds of it, rendered six ways, so you can see exactly what each format looks like before deciding which one you want.

Script or transcript?

Worth settling first, because it is the reason this search is confusing.

A script exists before recording. It is intent: an outline, an intro to read, questions to ask.

A transcript exists after recording. It is record: what was actually said, including the parts nobody planned. If you are publishing alongside a released episode, adding accessibility, or feeding text to a search index, you want a transcript. The W3C guidance on transcripts is a useful reference for what transcripts are for in accessible publishing.

Podcast transcript example formats at a glance

Here is the quick version of this podcast transcript example before we get into each format in full.

If you only need a rule of thumb:

1. Publishing on a website: clean read
2. Need jump links into audio: timestamped transcript
3. Uploading captions: SRT or WebVTT
4. Building search, QA, or AI workflows: JSON segments
5. Doing research or legal review: full verbatim

The source audio

Everything below is the same sixty seconds: two speakers, Sarah and Marcus, mid-conversation about a product launch. Real conversational speech, including the messiness, so the differences between formats are visible rather than theoretical.

1. Raw machine output

What automatic transcription actually returns before anyone touches it.

so the thing that surprised me i guess was that nobody like nobody actually asked for it we just we assumed and then we shipped it and it turned out that the two people who did ask were both on the same team right yeah that happens a lot more than people admit i think we spent what three months on that feature something like that yeah three months

No punctuation to speak of, no capitalisation of names, no paragraph breaks, and no speaker labels. None of that is unusual, and it is why raw output is a draft rather than a document.

The missing speaker labels matter in particular. A broader and safer way to say it is this: many transcription systems return timestamps but not reliable speaker labels by default. Identifying who spoke is a separate task called speaker diarization.

2. Clean read, the version you publish

Filler words removed, speakers marked, paragraphs at every change of speaker.

**Sarah:** The thing that surprised me was that nobody actually asked
for it. We just assumed, and then we shipped it, and it turned out the
two people who did ask were both on the same team.

**Marcus:** Right. That happens a lot more than people admit.

**Sarah:** I think we spent, what, three months on that feature?

**Marcus:** Something like that. Three months.

For most podcast episode pages, this is the format to aim for. The voice survives, the noise does not, and it is readable at a glance.

It is also the format most likely to help with on-site search, indexing, and actual reading. If someone lands on an episode page from search, this is usually what they hoped to find when they searched for a podcast transcript example.

3. Full verbatim, for research

Every repetition, every hesitation, kept deliberately.

Sarah: So, um, the the thing that surprised me, I guess, was that
nobody, like, nobody actually asked for it? We just, we assumed. And
then we shipped it and it turned out that the two people who did ask
were both on the same team.

Marcus: [laughs] Right, yeah. That happens a lot more than people
admit, I think.

Sarah: We spent, what, three months on that feature?

Marcus: Something like that. Yeah. Three months.

The hesitations are data here. "We just, we assumed" carries a self-correction that the clean version smooths away, and for qualitative research, legal work, or analysing how someone answers a hard question, that is the point.

4. Timestamped for navigation

Clean read with timing every few exchanges, which is what an episode page wants.

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

[00:29] Marcus: Right. That happens a lot more than people admit.

[00:41] Sarah: I think we spent, what, three months on that feature?

Enough to jump into the audio at the right moment, rare enough to stay out of the reader's way.

This is often the practical middle ground: readable like prose, still navigable like media.

5. Caption files

When a player or a podcast host wants captions, the same words carry per-cue timing. SRT and WebVTT are close relatives, but they are not identical. WebVTT has a published W3C specification, and the Library of Congress format description for SubRip, SRT is a solid reference for the older format.

1
00:00:14,000 --> 00:00:20,500
The thing that surprised me was that nobody actually asked for it.

2
00:00:20,500 --> 00:00:24,000
We just assumed, and then we shipped it.

3
00:00:29,000 --> 00:00:32,400
Right. That happens a lot more than people admit.

A quick way to think about the difference:

• SRT is simple and widely accepted by platforms
• WebVTT includes its own header and syntax, and is the web standard for timed text
• Both are built for cue timing and reading speed, not for long-form document readability

Notice how short each cue is. Caption files break on reading speed rather than on sentences, which is exactly why they read badly as documents.

6. JSON, for software

When a program consumes the transcript, keep the timing structured. The example below is a simplified example response shape:

{
  "text": "The thing that surprised me was that nobody actually asked for it...",
  "segments": [
    { "start": 14.0, "duration": 6.5, "text": "The thing that surprised me was that nobody actually asked for it." },
    { "start": 20.5, "duration": 3.5, "text": "We just assumed, and then we shipped it." },
    { "start": 29.0, "duration": 3.4, "text": "Right. That happens a lot more than people admit." }
  ]
}

Every other format on this page can be generated from this one. That is the practical argument for keeping the structured version even when you publish prose: timestamps to text is a formatting pass, and text back to timestamps means transcribing again.

For developers and data teams, this structure matters more than it first appears. Segment JSON is useful for:

• chunking transcript text without losing time alignment
• search indexing by segment instead of by giant page-length blobs
• subtitle conversion to SRT or WebVTT
• QA and research workflows that need exact audio locations
• embeddings and retrieval pipelines, where segment boundaries are usually more useful than paragraphized prose

If you are feeding transcripts into an app or LLM workflow, this is usually the source of truth.

Why transcript structure matters for AI pipelines

A transcript that reads beautifully is not always the best transcript for software.

AI and retrieval systems usually benefit from explicit structure:

• timestamps let you link answers back to audio
• segment boundaries keep chunks stable and easier to rank
• speaker turns help when meaning depends on who said what
• machine-readable fields make conversion and validation straightforward

A clean article-style transcript is great for people. A segmented transcript is usually better for search, retrieval, and downstream automation. If you need both, keep the JSON and generate the human-facing version from it.

Which one do you actually want?

Publishing an episode page: clean read, speaker names, a timestamp every few paragraphs.

Accessibility: usually a readable transcript, with speaker identification and meaningful non-speech audio included when relevant to understanding. The exact requirement depends on context and audience, and the W3C guidance on captions and transcripts is the right place to check conventions.

Captions in a player: SRT or WebVTT, whichever the platform asks for.

Feeding an app, a search index or an AI pipeline: JSON segments.

Research or legal: full verbatim, and say so in the document, because a reader needs to know the ums are deliberate.

Getting one for your own episode

If you have decided which format you need, the next step is straightforward.

For a single episode, paste the link into TranscriptFetch's free podcast transcript generator. It accepts a Spotify or Apple Podcasts link or an RSS feed, resolves the episode back to the publisher's real audio file, and transcribes that.

For a back catalogue, the podcast transcript API returns structured transcript data from the same inputs, one credit per episode no matter the length. The formatting conventions behind each style, verbatim versus clean read, speaker labels, where timestamps belong, are covered in podcast transcript format.

FAQ

What does a podcast transcript look like?

For a published episode page: speaker names in bold, a new paragraph every time the speaker changes, filler words removed, and a timestamp every few paragraphs. For software: a JSON array of segments, each carrying a start time, a duration and a line of text. Both are on this page in full, from the same sixty seconds of audio.

What is the difference between a podcast script and a podcast transcript?

A script is written before recording and says what people intend to say. A transcript is produced after recording and says what they actually said. Most search results for transcript examples are really script templates, which is why the two get confused. If you are looking for something to publish alongside a released episode, you want a transcript.

What does raw automatic transcription output look like?

Usually one long block with inconsistent punctuation, lowercase proper nouns, and no speaker labels or paragraph breaks at all. Treat it as a starting point rather than a finished document. The editing time between raw output and something publishable varies a lot with audio quality, accents, crosstalk, and whether speaker labels are required.

Which transcript format should I publish on my website?

The clean-read version with speaker names and paragraphs, as a real page with an episode summary and headings. Keep the timestamped JSON or caption file for machines and for jumping into the audio. Converting timestamps into readable prose is a formatting pass, while going the other way means transcribing again.

How long is a transcript of an hour-long podcast?

A rough estimate is 9,000 to 10,000 words if the conversation lands around 150 words per minute. That speech rate is only an average, and real episodes vary. The National Center for Voice and Speech notes that typical conversational speaking rates often fall in the neighborhood of 150 words per minute. That is why transcripts are usually something you search or summarise rather than read end to end, and why timestamps matter more than they do on a short piece of writing.