An episode nobody can find
Paste the transcript or a page of notes. You get a summary a stranger can decide on, six takeaways, a chapter list with the timestamps already in it, three quotable lines taken word for word, five titles and the tags the podcast apps index. Nothing in the episode is invented and no quote is rewritten.
The AI Podcast Show Notes Generator writes show notes from an episode title and a short description, with a summary, the points covered and quotes, in the tone and for the listeners you name. Timestamps and links go above the description, where listeners scan first.
Show notes are read before the episode, not after
Episode 47 arrives in a list of forty other episodes, in an app that shows three lines before the play button. In those three lines a listener decides something narrow and practical: is this the episode about the thing I was thinking about. The show notes are not a summary for people who already listened. They are the shop window for people who have not.
This is why the notes written after the fact read the way they do. The host remembers what was interesting, writes two paragraphs about the conversation, and forgets the only thing the app indexes: the words a listener would type into a search box. \"We talked about pricing with a friend of the show\" tells nobody anything. \"Why a 20% price rise lost 40% of the customers, and what he did instead\" is the same episode and a completely different listing.
There is a second reader most hosts never think about: the machine. Apple, Spotify and YouTube each take a description field, each truncate it in a different place, and each build a search index from it. The same text has to work in a 4,000-character field and in the 160 characters that actually get shown before the fold, which is why the summary here is written first and everything else follows it.
The chapter list is the only menu a listener gets
Five chapters, five reasons to keep listening. A chapter that says \"part two\" gives nobody a reason; a chapter that says what happens in it does. The timestamps come from the transcript, so the list matches the audio to the second rather than to the host's memory of it.
- 0:00The cold openthe question the episode answers, before anyone introduces themselves
- 2:14Where the number came fromthe source, and why it is not the number people quote
- 11:40The counter-argumentthe guest's own objection, kept in the edit
- 24:05What to do on Mondaythree steps, no theory
- 36:30The question nobody askedthe part that makes the chapter list worth reading
The chapter list is the only part of a long episode that a stranger reads. Written by hand it is a chore; written from the transcript it is five minutes of work.
If the transcript has no timestamps, the tool returns no chapters instead of guessing at them. A chapter list that is forty seconds off is worse than none: the listener scrubs, lands in the middle of an advert, and stops trusting the rest of the notes.
From transcript to published notes
Paste the real transcript
Not your outline, not the guest's bio. The tool needs the words that were actually said, because the quotes are checked against them.
Read the summary first
Two or three sentences, and they have to work alone in a search result. If they do not, the title is wrong, not the summary.
Fix the chapter names
The list is a menu: every line should name a decision, a story or a number. "Part two" is deleted.
Paste the tags last
Ten words a listener would type. The app's own categories go in the category field, not in the tags.
One episode, four listings
| Place | Field length | What it shows | What to put there |
|---|---|---|---|
| Apple Podcasts | about 4,000 characters | the whole description, links allowed | summary, chapters, guest links, credits |
| Spotify | about 4,000 characters, HTML stripped | the first lines, then \"read more\" | put the chapter list first, links after it |
| YouTube (episode video) | 5,000 characters | the first two lines above the fold | the same summary, then timestamps, because YouTube turns them into chapters |
| Your own site | no limit | a page that can rank in search | the transcript, plus the summary as the introduction |
| Social post | 2,200 on most apps | one hook and a link | the pull quote, not the summary |
The order is not the same in all four. Apple reads past the fold, YouTube turns a list of timestamps into chapters only when the first one is 0:00, Spotify strips the markup and shows the first two lines. Writing the summary once and pasting it everywhere is how an episode ends up invisible in three of the four places.
Three decisions the tool cannot make for you
A guest episode is the guest's search traffic as much as yours. Put their name in the title only if the name is known; otherwise put the problem they solve there and the name in the description. A title is a promise, and \"with someone you have not heard of\" is not one.
The tool writes the titles from the transcript, so it will use the strongest claim in the episode rather than the most flattering one. Keep that. The flattering version is for the newsletter.
Long episodes need the chapter list more, not less. Above an hour, a listener is choosing between your episode and a different episode, and the chapters are the only evidence that the interesting part is in there somewhere.
Under twenty minutes, the summary and the chapters say nearly the same thing. Drop the chapter list and spend the space on the two or three sentences that make somebody press play.
Timestamps that do not exist, quotes that were paraphrased, promises about the next episode, and links to things that were mentioned but not published yet. The tool is instructed to use only what is in the transcript, and the quote check throws away anything it cannot find in the source - a quote that is almost right is a correction waiting to happen.
Sponsor reads are the exception worth handling by hand: they have their own required wording, and no generator should be inventing it.
Writing show notes that get an episode found
Start from the transcript, not from the episode plan
The plan says what you intended to talk about. The transcript says what you said, which is usually better and always more searchable: the guest's own phrasing, the number that came up, the objection that took ten minutes to answer. Every one of those is a phrase a listener might type. The generator works from the transcript for exactly this reason - it has no access to your intentions, only to the words.
A rough machine transcript is enough for the summary and the takeaways, but the quotes need cleanup. If a sentence reads \"we we we found that that the price\", fix it before you paste it: the quote check looks at the source, so a messy transcript produces no quotes at all, which is the correct outcome rather than a wrong one.
The summary is the only paragraph that gets read
Two or three sentences, no greeting, no \"in this episode we\". The first sentence should contain the thing the episode is about in the words a person would use to search for it. The second can say who it is for. The third is optional and usually the place where the guest's name belongs.
Read it back as if it were the only thing you saw in a list of forty episodes. If you would not press play, the problem is not the length of the summary, it is that the episode's most interesting claim is not in it.
Chapter names that work as a table of contents
Write each chapter as if it were a heading in an article: a noun phrase that says what happens, or a question the chapter answers. \"The 20% price rise\" is a chapter. \"Talking about pricing\" is a topic. The difference matters most at the two ends of the list, because the first chapter tells a listener whether to start and the last one tells them whether to stay to the end.
Six to eight chapters suit an hour. More than that and the list becomes a transcript with times attached; fewer and it stops being a menu.
Quotes are a different kind of asset
A pull quote has two jobs: it goes in the social post, and it gives a journalist or a newsletter a sentence they can lift with attribution. That is why the tool only keeps lines it can find in the transcript. A quote that sounds better than what was said is a liability the first time somebody listens to the episode and checks.
Pick the quote that is surprising, not the one that is representative. \"We deleted the pricing page and signups went up\" travels; \"pricing is important\" does not.
Tags, categories and the long tail
The ten tags are not hashtags and they are not your episode's themes. They are the words somebody types into a podcast app: the guest's field, the problem, the tool, the place. Podcast search is smaller and less competitive than web search, which means a specific phrase has a real chance of placing an episode that a broad one never will.
Keep the tags stable across episodes. An app that sees the same five tags every week learns what the show is about; a new set of ten every week teaches it nothing.
The workflow that survives a weekly schedule
Record, transcribe, paste, generate, edit for ten minutes, publish. The ten minutes are not optional: the generator writes a solid draft and a stranger's ear catches what a model cannot - the inside joke that needs a line of context, the guest's name spelled two ways in the transcript, the chapter that starts on the advert.
Run the tool once per episode and keep the output in the same document as the transcript. Six months later, when somebody asks for the episode where you discussed a specific number, the file with the summary and the chapter list is the fastest way to find it - and the notes become an archive rather than a form you fill in at midnight.
Questions before the first episode
Do I need a full transcript?expand_more
Why did it return no chapters?expand_more
Why are there only two quotes instead of three?expand_more
Can it write notes for a video podcast?expand_more
Does it write the guest bio?expand_more
Turn tonight's recording into notes
Paste the transcript, take the summary, the chapters and the quotes to your podcast host.
fact_checkQuick facts
- Show notes are scanned rather than read, so timestamps and links belong above the description.
- A listener decides from the first line whether the episode answers the question they searched for.
- A language model reads text in tokens, and one token is roughly four characters of English, so a 300-word answer is about 400 tokens.menu_bookOpenAI Cookbook
- The output depends on the prompt: the same request with a different tone or length instruction produces a different text, not a different answer quality.menu_bookOpenAI Cookbook
- WebVTT is the format the HTML video element reads for captions, and it separates the millisecond with a dot.menu_bookW3C
helpQuestions people ask
What should podcast show notes include?expand_more
Do show notes help podcast discovery?expand_more
How long should show notes be?expand_more
hubWhat this page is about
- Large language modelopen_in_new
A model that predicts the next token of a text; the site sends the prompt to a hosted model and returns its answer.
- WebVTTopen_in_new
The W3C subtitle and caption format used by the HTML video element, with cue timings written as 00:00:01.000.
library_booksOfficial sources cited on this page
Keep going with the next tool
The tools in this group that do the next piece of the same work, all switched on right now.
Switched-off tools are not listed here: only what works right now.