How to get a transcript from a YouTube playlist

Forty hours of lectures sat in one YouTube playlist. Twenty eight recordings, most of them between seventy five and ninety five minutes, one module, six days before the paper. Watching them again was not going to happen. Watching half of them was not going to happen either. The only honest question left was whether the words could be read instead of heard, and whether reading them would actually help or just feel like work.

So we searched for how to get a transcript from a YouTube playlist, and found the same page thirty times. Bulk exporters promising 350 videos in three minutes. Free downloaders listing TXT, JSON, CSV, SRT and VTT like a menu. Browser add-ons that put a Transcribe button on a channel page. Open source scripts that run local speech recognition across a playlist overnight. All of them stop at the same place: you now have the files. Congratulations. Nobody says what a student is supposed to do with twenty eight text files on a Tuesday night.

This is the missing half. How the export works, what it costs in time, what came back broken, and the study loop we actually used once the files were on disk. A plain disclosure first: YouTubeScribe is our product, and the playlist tool described here is ours. We have tried to be exact about what it does and blunt about what it does not do. Where a number is an estimate rather than a measurement, it says so.

What a YouTube playlist transcript actually is

There is no such object as a playlist transcript. A playlist is a list of video ids with an order attached. YouTube stores no combined text for it. When any tool says it exports a playlist transcript, what it is really doing is reading the list, then fetching one transcript per video, then putting the results in a folder or stitching them together. Twenty eight fetches. The word playlist is doing marketing work, not technical work.

That matters for two reasons. First, the job scales with video count, not with playlist size on screen. A playlist of four hundred short clips is more work than a playlist of twelve long lectures, even though the second one holds far more hours. Second, each fetch can fail on its own. A playlist export is a set of independent results, and a set can have holes in it.

The second thing worth being clear about is where the text comes from. YouTubeScribe reads the caption track that a public or unlisted video already has. It never runs speech recognition on the audio, and it never invents speech. If the uploader added captions, you get their captions. If YouTube generated captions automatically, you get those. If neither exists, you get a reported miss rather than a made up paragraph. That is the whole design, and it explains both the speed and the limits described below.

Two kinds of track, and why the difference shows up in lectures

Uploader captions are written or corrected by a person. They have punctuation, sentence breaks, sometimes speaker labels, and the technical vocabulary is usually spelled correctly. University channels that care about accessibility often have these, because captions are an access requirement rather than a nicety.

Automatic captions are produced by YouTube from the audio. They are genuinely good on clear speech in a quiet room, and they get noticeably worse on the things lectures are full of. Reading a term of auto captions teaches you exactly where the seams are.

• Proper nouns. Author names, theorem names, place names and drug names get approximated into ordinary words.
• Anything read aloud from a board. Formulas, equations and code become word soup, because the speaker is saying symbols out loud.
• Acronyms. They arrive as separate letters, as a plausible different acronym, or as a real word that sounds similar.
• Overlapping voices. Seminar discussion and question time are the weakest part of almost every track.
• Silence with meaning. Long pauses while the lecturer writes produce nothing, so a transcript can skip the single most important minute.
• Accents the model handles less well, which is a real and uneven cost across a department.

None of that makes the transcript useless. It makes it a finding aid rather than a substitute. You search the transcript to find the six minutes you need, then you watch those six minutes. That framing survived the whole week and is the single most useful idea in this post.

Timestamps are the point, not a formatting detail

Caption tracks are timed text. Every line carries a start time and an end time. SRT and VTT keep those times. A plain TXT export throws them away and gives you a wall of prose. Both are useful, and for revision they are useful for different things.

TXT is what you read and paste. SRT is what you search when you need to jump back into the video at the right second. Keeping both costs nothing except a slightly fuller folder, and by day three of revision week the SRT files were the ones being opened. On YouTubeScribe, TXT and SRT are both free, and VTT is a Pro format. The first transcript each day is free, and nothing is stored on the free tier.

One at a time, or all at once

The manual route works and it is free. On a video with captions, open the description, choose Show transcript, and YouTube shows a scrollable panel next to the video. There is a toggle to hide timestamps. Select the panel, copy, paste into a text file, save with a sensible name. That is it. No account, no tool, no cost.

Timed with a phone across five lectures, the honest per video figure was about five minutes: roughly forty seconds of clicking and copying, and the rest spent finding the video in the playlist, deciding what to call the file, and fixing the paste when the panel had not fully loaded. Call it five minutes each, and twenty eight lectures is two hours and twenty minutes. That is illustrative, not measured across a large sample, and your number will move depending on how fast you name things.

Two hours and twenty minutes is not nothing during revision week, but it is also not a disaster. If you have one module and a free weekend, do it by hand and keep your money. The batch route exists because two hours and twenty minutes becomes seven hours across three modules, and because the manual route is the kind of task where attention leaks. Around lecture nineteen you stop naming files carefully, and an unnamed file is a lost file.

What the batch route changes

Playlist Transcript Export takes a playlist URL, reads the list of videos, and fetches each caption track in turn. It is a Pro feature, and the reason is not clever technology. It is that a batch of fetches costs us a batch of fetches. Doing exactly the same thing by hand, one video at a time, is free and slow. That is the trade, stated plainly, and if the free and slow version fits your week then take it.

Speed on our side is dominated by the length of each video rather than by a queue. There is no hard length cap, and a three hour recording takes about twelve seconds. Caption tracks exist in 125 languages, and the export can pull whichever track a video actually has, which matters if your module mixes a lecturer recording in English with a guest lecture recorded in Spanish.

Those times are illustrative. They come from one student, one laptop, one module, in June 2026, and they are meant to show the shape of the difference rather than to be quoted as benchmarks. The rewatch rows assume you actually sit through the videos, which nobody does, which is exactly why the rewatch plan quietly fails.

The third route: local speech recognition

There is a whole category of open source scripts that point a local Whisper style model at a playlist and generate text from the audio. They work. People run them overnight on a laptop with a decent GPU and wake up to a folder of transcripts. If you want to see what that looks like, the bulk transcribe playlist project on GitHub is a readable example.

The trade is time and heat. Generating text from audio is a much heavier job than reading text that already exists, by a wide margin. Forty hours of audio is a long evening at best on consumer hardware, and the quality still depends on which model size you can fit in memory. YouTubeScribe does not do this. We read the track that is there. The two approaches are answers to different questions: ours is faster when a track exists, and local speech recognition is the only answer when a track does not exist and you cannot get one any other way.

The export was never the hard part. The hard part was Thursday, when I had all the files and still did not know which lecture had the bit about selection bias.

YouTubeScribe study log, June 2026

The setup: 28 lectures, named so you can find them

Do this once, at the start, while you still care about tidiness. Every step below exists because skipping it cost time later.

1. Make one folder per module, named with the module code, for example STAT201. Do not put two modules in one folder, even if they share a lecturer.
2. Open the playlist on YouTube and check it is public or unlisted. A private playlist cannot be read by any external tool, including ours, and no tool that claims otherwise is telling the truth.
3. Count the videos and write the number down. You will compare against it later, and you will be glad you did.
4. Copy the playlist URL from the address bar. Make sure it is the playlist URL and not a video URL that happens to have a playlist attached, because the second one can export a single video instead of the set.
5. Open the Playlist Exporter at /tools/playlist-exporter and paste the URL.
6. Choose both TXT and SRT. TXT is for reading and pasting. SRT keeps the timestamps you will need on day three.
7. Run the export and let it finish. Do not close the tab to go and check something, because a half finished batch is worse than no batch.
8. Read the result list before you touch the files. Note every miss. Those are lectures with no caption track, and they need a different plan.
9. Rename every file to the pattern 01-week1-what-regression-is.txt. Number first, week second, three or four words of the actual topic third. The number keeps sort order, the topic makes search work.
10. Open two files at random and read a paragraph of each. You are checking that the text matches the lecture you think it is, because a mislabelled playlist entry is common and easier to catch now than on Friday.
11. For each miss, decide immediately: ask the module page whether a captioned copy exists, ask a friend for notes, or accept that you will watch that one properly.
12. Back the folder up somewhere you control. Read the note about shared drives further down before you pick where.

Naming, in more detail than it deserves

This is the least interesting part of the workflow and the one that made the biggest difference. Default names from any exporter are some combination of video title and video id, and lecture video titles are hostile. Half of them are the module code repeated twenty eight times. Others carry a recording date, a room number and the word FINAL.

• Start with a two digit number. 01 to 28 keeps the folder in lecture order in every file browser, which single digit numbers do not.
• Put the week next, because your reading list and your exam revision plan are both organised by week, not by lecture number.
• Then three or four words of real topic, in lower case, separated by hyphens. Write what the lecture was about, not what it was called.
• Keep the video id out of the filename. It is noise when you read and it is not what you search for.
• Use the same pattern for the SRT files, so the pair sits together when the folder is sorted by name.

One file per lecture, never one file for the term

Some exporters offer a merge into one document, and it looks like the tidy option. We tried it. Details of why it failed are in the last section, but the short version is that a single term long file makes search noisier and breaks the link between a timestamp and a video. Keep twenty eight files. Folders are free.

What to do with 28 files

Here is the part every tool page skips. A folder of transcripts is not revision. It is a searchable index of a term, and it only pays off if you use it as one. The loop below took about twenty minutes to learn and was used forty or fifty times across a week.

The loop: question, search, jump, watch six minutes

Start from a question, not from a lecture. Open your past paper, your problem sheet, or your list of things you do not understand, and take one item. Search the whole folder for a phrase from it. You are not looking for the lecture, you are looking for the two minutes inside the lecture.

Every operating system can search a folder for text. On macOS, Spotlight indexes text files and matches on content as well as filenames. On Windows, File Explorer search finds text in plain files once indexing is on for that location. If you already have a code editor installed, drag the folder into it and use the folder wide search, which shows every match with surrounding lines and is by some distance the best experience of the three. On a terminal, grep with the recursive and case insensitive flags does the same job in one line.

The result is a list of files with matching lines. Pick the most promising, open the matching SRT rather than the TXT, and read the cue time next to the match. Now open the video and jump to about thirty seconds before that time, because lecturers introduce a concept slightly before they name it. Watch six minutes. Stop. Go back to your question list.

That is the entire method. It sounds too simple to be worth writing down, and it replaced roughly thirty of the forty hours.

Search terms that work, and ones that do not

• Search for phrases a lecturer says out loud, not for textbook headings. Nobody says the words chapter summary during a lecture.
• Search for the mistake, not the concept. The phrase people get this wrong finds the five minutes where the tricky part is explained.
• Search for two or three word fragments rather than whole sentences, because auto captions break sentences in unpredictable places.
• Search for a name if a method is named after someone, since names survive auto captioning better than symbols do.
• Do not search for anything you would write in a formula. Symbols read aloud become words, and the words are unpredictable.
• If a search fails, try the everyday word the lecturer would use with a first year, not the precise term from the syllabus.

Where the other tools fit, and where they do not

Playlist Transcript Export is the one that matters for this job. Four others came up during the week, each for a narrow purpose.

The Transcript Generator is for a single video that is not in your playlist, which happens constantly, because half of revision is watching someone else explain the thing your lecturer explained badly. The Chapters Extractor pulls the chapter markers a video already has, and on a well produced lecture series those chapters are a ready made outline of the module, which is a fast way to build a revision checklist without reading anything. Chat With Video was useful in exactly one situation: one lecture where the transcript was dense enough that finding the right section by search kept failing, and asking a question about that single video was quicker than reading the whole thing. Video to Study Notes was used twice, on the two lectures we had never attended at all, to get a rough first pass before watching them properly.

Notice what those last two have in common. They were used on the small number of lectures where the ordinary loop was not working, at the end of the week, when the cost of being wrong was low. They were not used as the main method, and there is a reason for that in the next section.

Transcripts as a writing input

One more use worth naming. When an essay question asked for a lecturer's own framing of a debate, having the transcript meant quoting the framing accurately instead of remembering it approximately. Search the folder, find the passage, note the lecture number and the timestamp, and paraphrase from the actual words. That is more honest than paraphrasing from a memory of a memory, and it takes two minutes.

What went wrong, and the rules we kept

Three things were tried on day one that were quietly abandoned by day three. They are the most useful part of this post, because they are all things the tool pages will never tell you.

We summarised every lecture on day one

It felt like the obvious first move. Twenty eight transcripts in, twenty eight summaries out, and revision becomes reading twenty eight pages instead of watching forty hours. The summaries were produced. They read well. They were not trusted.

The problem was not that they were wrong. Spot checks found them mostly right. The problem was that there was no way to know which parts were right without going back to the source, and on a topic you do not understand yet, you cannot tell a correct summary from a confident one. So every time a summary mattered, the transcript got reread anyway. That is the full cost of summarising first: you pay for the summary and then you pay for the source, and you end up slower than if you had gone to the source directly.

The rule that replaced it: summarise on demand, never in advance. When a specific lecture turned out to matter, a summary of that one lecture was genuinely useful, because by then there was enough context to check it. Twenty eight summaries produced up front is a folder of documents you do not believe.

We made one giant file for the whole term

The merge option looked tidy. One file, one search, no folder to navigate. It caused two specific problems, both annoying enough to undo it.

First, search got noisier rather than faster. A module repeats its own vocabulary constantly, so searching for a core term in a merged file returned two hundred hits with no way to tell which lecture each came from. Twenty eight separate files return a ranked list of filenames, and the filename tells you the week, which tells you whether the hit is likely to be the introduction or the hard version.

Second, and worse, the timestamps collided. Every transcript starts at zero. Merged into one document, the file contains twenty eight separate stretches of 00:14:32, and a timestamp that does not identify a video is not a timestamp, it is a number. The whole jump back into the video habit stopped working, which was the single most valuable thing about having the files.

The rule that replaced it: one file per lecture, always. If you want one document for reading on a train, make that as an extra, and keep the per lecture files as the thing you search.

We watched at 2x while reading the transcript

This one felt clever for about fifteen minutes. Play the lecture at double speed, follow along in the transcript, absorb twice as much. What actually happens is that you do neither task properly. Reading is faster than double speed speech, so you finish each paragraph early and wait. Then the audio says something the transcript rendered differently, and you stop to work out which is right. Then you have lost your place in both.

Reading and listening are competing for the same attention, and splitting it produces two half quality passes rather than one good one. Pick one. Read the transcript to find the part that matters, then watch that part at normal speed with the transcript closed. That combination worked. The combined version did not.

The misses, and the guest seminar

Twenty eight videos produced twenty six transcripts. Two misses. One was a guest seminar recorded on somebody's phone at the back of a room, uploaded without captions, and never automatically captioned because the audio was poor enough that YouTube produced no track at all. The other was a short administrative video with almost no speech in it, which turned out not to matter.

That ratio is normal. In a 28 video playlist, expect the odd miss, and expect the guest seminar to be the one. Guest talks are the classic case: recorded by a different person, on different equipment, uploaded in a hurry, sitting in the playlist looking exactly like every other entry until you try to read it.

The useful response is not to fight it. Options, in order of how well they worked: check whether the department posted a captioned copy elsewhere, because they often do for accessibility reasons; ask whether anyone recorded the slides with narration; ask a friend who attended; or accept it and watch that one lecture in full, which is one lecture, not twenty eight. Running local speech recognition on it is a real option too, and it is the situation where that heavier approach earns its cost, because there is no track to read.

What we kept

• One folder per module, one file per lecture, numbered names with the real topic in them.
• Both TXT and SRT, every time. The SRT files were used more than expected.
• Search first, from a question, not from a lecture.
• Jump into the video thirty seconds before the timestamp, and watch six minutes, not sixty.
• Summarise one lecture when that lecture matters. Never summarise all of them up front.
• Read the miss list before touching the files, and deal with misses on day one while there is still time.
• Check the module rules before putting a term of transcripts anywhere shared.

The exam went fine. Not because forty hours were compressed into six by a clever tool, but because the forty hours became searchable, and about six of them turned out to be the ones that mattered. The tools that rank for this keyword will tell you how fast they can produce files. The files are the easy part. What you do on Thursday is the rest of it.

Questions people ask

Sources

1. YouTube Help. Use automatic captioning. support.google.com· Checked 17 August 2026.
2. YouTube Help. Supported subtitle and caption files. support.google.com· Checked 17 August 2026.
3. YouTube Help. Add subtitles and captions. support.google.com· Checked 17 August 2026.
4. W3C. WebVTT: The Web Video Text Tracks Format. w3.org· Checked 17 August 2026.
5. Google for Developers. YouTube Data API: Captions. developers.google.com· Checked 17 August 2026.
6. YouTube Help. View video transcripts. support.google.com· Checked 17 August 2026.
7. Google for Developers. YouTube Data API: PlaylistItems. developers.google.com· Checked 17 August 2026.
8. Google for Developers. YouTube Data API: Playlists. developers.google.com· Checked 17 August 2026.
9. Google for Developers. YouTube Data API: Videos. developers.google.com· Checked 17 August 2026.
10. Google for Developers. YouTube Data API: Determine quota cost. developers.google.com· Checked 17 August 2026.
11. GitHub. Dicklesworthstone/bulk_transcribe_youtube_videos_from_playlist. github.com· Checked 17 August 2026.
12. GitHub. openai/whisper. github.com· Checked 17 August 2026.
13. GitHub. jdepoix/youtube-transcript-api. github.com· Checked 17 August 2026.
14. GitHub. yt-dlp/yt-dlp. github.com· Checked 17 August 2026.
15. MDN Web Docs. WebVTT API. developer.mozilla.org· Checked 17 August 2026.
16. W3C Web Accessibility Initiative. Captions and subtitles. w3.org· Checked 17 August 2026.
17. YouTube Help. Create and manage playlists. Cited by title, URL not verified. Checked 17 August 2026.
18. YouTubeScribe. Study log, June 2026.

Reviewed on 17 August 2026. If a line is wrong, email support@youtubescribe.com.