How to turn a podcast transcript into a blog post
Going from podcast transcript to blog post is a rewrite, not a clean-up. A working method: find the claims, build a structure, quote only where words matter.
A transcript is raw material for an article, not a draft of one. Spoken English repeats itself, backs up mid-sentence, and leans on tone to carry meaning the words never state. So the work of going from podcast transcript to blog post is a rewrite: export the plain text, find the three or four things the episode actually claims, build a structure out of those, then write each section in sentences that hold up on a page. Here is the method, from the export to the published article.
Going from podcast transcript to blog post is a rewrite, not a clean-up
Read the transcript of a minute you enjoyed listening to and the gap is obvious. On the page, a fluent speaker produces something like this: “And I think, I mean, the thing about pricing, right, is that you, you sort of price against the other guys, which is, that’s the mistake, that’s the whole mistake.”
Nothing is wrong with that as speech. It was clear at the time, because the speaker slowed down on “that’s the whole mistake” and the host nodded. On the page it is a mess, and no amount of comma-fixing rescues it. It means one sentence: pricing against a competitor instead of against the outcome is the mistake. That sentence is what goes in the article.
Treat the transcript as a source you are reporting from. Here is what it hands you, what an article needs, and the move in between.
| What the transcript gives you | What the article needs | What you do about it |
|---|---|---|
| One block of speech in the order it happened | A shape a reader can skim | Rebuild around the claims, not the conversation |
| The same point made three times, better each time | One statement of each point | Keep the clearest pass, cut the other two |
| Filler and false starts, “I mean”, “right”, “sort of” | Sentences that stand on the page | Rewrite them out, except inside a verbatim quote |
| Lines that only worked because of tone | Meaning carried by the words | Restate plainly, or leave them out |
| Names and URLs spelled as they sounded | Links a reader can follow | Look every one up before you publish |
| Figures said aloud, sometimes misheard | Numbers a reader can trust | Check each against the audio, write them as digits |
| No pictures, because it was audio | Something to look at in a long read | Draw the process the guest described in words |
Start from the plain text export and read it once
Export TXT, not SRT or VTT. A subtitle file chops the same words into two-line cues with a timecode between each pair, which destroys the paragraph as a unit and makes you fight the file before you can read it. Keep the subtitle export too if you want to link back to moments in the audio, but write from the plain text.
If you still need the transcript itself, FreeTranscribe runs the speech model in your browser, so an unreleased episode never leaves your machine, and it exports all three formats. The limits, plainly: desktop Chrome or Edge, English, and the base model, which means names and jargon need checking.
Then read the whole thing once without editing anything. Editing on the first pass locks you into the running order, which is the thing you are trying to escape. Mark the three or four things the episode actually claims.
A claim is a sentence the episode would defend, not a subject it touched. “Pricing” is a subject. “We priced against the cheapest competitor and it cost us two years of margin” is a claim. If you cannot find three claims in an hour of talk, the episode may not be an article. It may be show notes with chapters and a pull quote, which is a different and much faster job.
Build the structure from the claims, not the running order
Conversations circle. A guest gestures at a point at minute eight, half-retracts it at twenty-four, then states it properly at fifty-one because by then the host has asked the right question. That order is where the two of them happened to get to, and almost never the order a reader needs.
So make each claim a heading in an empty document, then move every passage that touches a claim under its heading, wherever in the episode it came from. Put whatever is left in a section at the bottom called “cuts”. The fifty-first-minute version of a point now sits next to the eighth-minute version, and you can see at a glance which to use.
When nothing is left to move, the cuts section is your answer to “what gets dropped”, already decided. Order the sections by what the reader needs first, usually the claim that stands up without the other two.
Rewrite each section in written English, and quote only where the exact words matter
Now write. One point per paragraph, the point in the first sentence. Cut “so”, “you know”, “I mean” and “right” wherever they are not doing work. When a speaker hedged, decide what they meant, the claim or the qualification, and write that. If you cannot tell, listen back to those ten seconds rather than guessing on the page.
Quote verbatim in four situations: the phrasing itself is the point, the speaker is committing to something, a number is involved, or the statement is contested. Everywhere else, paraphrase. A paraphrase is usually shorter and clearer, and the reader loses nothing.
Verbatim means verbatim. You may drop an “um”, mark a cut with an ellipsis, and put a word in square brackets where the speaker said “it” and the reader needs “the second round”. You may not smooth the grammar or swap a word for a better one. If a quote needs that much help, it was a paraphrase all along.
Attribute every quote to a person by name. “The guest said” is not attribution. Full name and role the first time, surname after that. Speech recognition does not label speakers, so the export arrives as one undivided block and you add the names yourself as you read. Adding speaker labels to a two-person interview covers the quickest way to do it.
Add what the audio could not carry
An article can do things an episode cannot, and this is where value gets added rather than moved across.
- Links. Every paper, product, company and person the guest mentioned, looked up and checked, because the model spelled them phonetically.
- Numbers as digits, with units, and a date where the figure will age.
- A diagram or a small table for anything the guest explained in two minutes of words, which is the clearest sign a picture was missing.
- The context listeners already had: who the guest is, what happened in the previous episode, what the argument is answering.
- A line saying which episode this came from, with a link and the timestamp of the passage.
Write a headline and a first paragraph that answer the question
Episode titles tease, because a listener is already in the app choosing what to play. Article headlines answer, because a reader is deciding whether this page is the one. “Episode 47: pricing, with Sarah Smyth” is a file name. “Pricing against your cheapest competitor costs more than it wins” is a headline.
The opening works the same way. Give the answer in the first two sentences, then say who said it and where it came from. After two hours inside a transcript the temptation is to set the scene first. Resist it. A reader who wants the scene will read on. A reader who wants the answer will leave if you make them hunt.
Decide whether to publish the full transcript underneath
Two reasons to publish the whole corrected transcript alongside the article, both worth stating modestly.
The first is access. Some readers cannot use the audio at all. Others are somewhere they cannot listen, or want to check a single line without scrubbing through an hour. A transcript gives all of them the episode.
The second is that an audio file carries no text of its own. The words spoken in the episode appear nowhere on the page, and a transcript at least gives them a text version that can be indexed. That is the whole of the argument. It is not a promise about rankings, and anyone quoting you a percentage for it is making the number up.
Against it: length, and the risk of a half-corrected transcript putting the guest’s name in print wrong. So correct it first, and give it its own page linked from the article rather than five thousand words sitting under your fifteen hundred. Link the two both ways.
Either way, you need the transcript first. Transcribe the episode in your browser and the file stays on your computer: free, no account, no length limit.
Frequently asked questions
How long does the article take once the transcript exists? As a planning figure rather than a measurement, budget half a day for a one-hour episode: about thirty minutes to read and mark, an hour to sort passages under the claims, the rest writing and checking links. The second one is much faster than the first.
Can I clean up the transcript and publish that instead? You can, and it is a legitimate thing to publish. It is a transcript page, not an article. It serves a reader who wants the episode in text, not a reader who arrived from a search wanting the answer.
How much of the episode ends up in the article? A small fraction. Most of a transcript is two people finding their way to the points, which is good listening and dead weight on the page. If your draft is as long as the conversation felt, you have transcribed rather than written.
Do I need to check quotes with the guest? Not as a rule, and it is a courtesy question rather than a legal one, but it is worth doing when a quote is sensitive, when it names a third party, or when the guest was thinking out loud. Send the paragraph, not the whole draft.
Should the article and the show notes live on the same page? No. Show notes serve someone who just listened and wants the links and the chapters. The article serves someone who has never heard the episode. Write both, and link each to the other.
Sources, checked 15 September 2026
- None fetched. This post makes no claim about any third-party product, platform or standard, and the description of the tool on this site is our own.