Free YouTube subtitle extractor: the complete guide

Type free YouTube subtitle extractor into a search box and every result reads the same: paste a link, wait ten seconds, download a file. Our own guide, Free YouTube subtitle extractor: every method that still works, is one of those pages, and it does that job properly, covering all four practical routes step by step. This page sits a level above it. It answers the questions that come after the file has already landed in your downloads folder: is copying someone's captions actually legal, why does one free tool feel safer to use than another, what does accurate even mean when every tool reads the same source file, and who is actually running these things at scale, and for what.

One disclosure before anything else. YouTubeScribe is our product, and it is one of the extractors this page is describing. That does not change what follows. The accessibility law, the file standards and the accuracy evidence below apply the same way to every tool in this category, ours included, and where our own tool falls short of a claim, the sections ahead say so plainly rather than skip past it.

What a free YouTube subtitle extractor is

Extractor, downloader and transcriber get used as if they mean the same thing, and in casual search they mostly function that way. Underneath, they describe three different jobs, and mixing them up is where most of the confusion in this category comes from.

An extractor reads a timed text track a video already has and copies it out as a file. That is the job this whole site is built around, and it is the cheapest of the three, because nothing has to be computed, only fetched.

A downloader is the same job under a different, equally common name. People searching for free YouTube subtitle downloader and free YouTube subtitle extractor want the identical result, so treat the two terms as synonyms for the rest of this page and everywhere else on this site.

A transcriber runs speech recognition on the audio and writes brand new text. It works even when no caption track exists, because it never needed one, but it costs real compute time, and it can be wrong in a way a copied file cannot be: it invents plausible words for audio it misheard, rather than returning an honest blank.

The confusion is not academic. Someone who actually wants a transcriber, because their video genuinely has no track, but who searches only for extractor, will land on ten tools that all do the same limited job and wonder why none of them work. The reverse also happens: someone who only needs a fast copy of an existing track ends up on a slow, paid transcription service because that was the first result. Naming the job correctly before you start searching saves more time than any single tool choice does.

Free YouTube subtitle extractor: every method that still works walks through the four practical routes to a file, step by step, with timings for a real 20 minute video. This page assumes you either already know that ground or do not need it yet. Some videos have no track to extract at all, no matter which route you take, and Why some YouTube videos have no captions covers those reasons in full. What follows here spends its time on the questions underneath the mechanics: is any of this legal, how do you judge one tool against another, what does accurate actually mean, and who is doing this at scale, and why.

The law that put captions on the page

Captions did not become common because every creator independently decided accessibility mattered. They became common partly because law started requiring them, first for broadcasters, then increasingly for the open web. Knowing roughly which rule applies where explains why captions show up reliably in some corners of the internet and patchily in others.

Almost every rule below eventually points back to the Web Content Accessibility Guidelines. Two success criteria matter here. 1.2.2 Captions (Prerecorded) is a Level A requirement: prerecorded video with audio needs captions. 1.2.4 Captions (Live) raises the bar to Level AA for live audio content, such as a livestream. Level A is the floor. Almost every accessibility law that references WCAG asks for at least Level AA, which pulls both criteria into scope.

In the United States, the Department of Justice published a rule under Title II of the Americans with Disabilities Act covering state and local government websites and mobile apps. It adopts WCAG 2.1 Level AA as the technical standard and names captions for video content specifically. The rule took effect 24 June 2024. It reaches government bodies directly rather than private companies, but it is the clearest recent US signal that captions are treated as an access requirement rather than a courtesy.

Separately, US federal agencies operate under Section 508, which requires captions and transcripts on the multimedia content of federal websites. Section508.gov spells this out plainly for the agency teams building or buying that content, rather than leaving it to a general accessibility statute to imply.

Broadcast content has its own rule, and it works differently. The 21st Century Communications and Video Accessibility Act requires that video programming originally shown on US television with captions keep those captions when the same programming is later delivered over the internet. It does not create a captioning requirement out of nothing. It carries an existing TV captioning obligation across to IP delivery, and the FCC documents the mechanism on its own pages for both the general rule and the wider CVAA. The obligation sits with the distributor moving the programme online, not with a viewer who later extracts the text for their own notes.

Outside the US, the UK's Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 requires public sector websites and apps, meaning government departments, councils and many publicly funded bodies, to meet WCAG 2.1 Level AA, which folds in the captioning criteria described above. A council uploading a planning meeting to YouTube and embedding it on its own site is a plain example of where this regulation and the WCAG criteria meet in the same video.

What the law does not reach

It is worth being precise about the gap. Every rule above attaches to a publisher: a government body, a federal agency, a broadcaster, an EU-regulated service. None of them reach an individual YouTube creator uploading a video from a bedroom, and YouTube's own upload flow does not require captions on any video before it goes live. That gap is exactly why automatic captioning exists as a platform feature in the first place, filling in where no legal obligation forces a human to caption anything, and why so much of what actually gets captioned on YouTube is either automatic, or added by creators who simply chose to, rather than by anyone required to.

Wider still, the European Accessibility Act, Directive (EU) 2019/882, sets accessibility requirements across a range of products and services sold in the EU. Article 3(6) specifically names subtitles for the deaf and hard of hearing among the requirements for audiovisual media services. Its obligations apply from 28 June 2025, which makes it one of the more recent pieces of this picture rather than one already fully bedded in everywhere.

None of these laws mention subtitle extraction tools directly. They govern the creator or the platform publishing the video, not a third party reading it afterward. What they explain is why captions are now common enough that an extractor has something to read on a large share of videos, particularly from organisations publishing under one of these obligations.

The practical effect shows up unevenly across the platform. A national broadcaster's YouTube channel, a university's lecture uploads, or a government department's public briefings are far more likely to carry a proper caption track, because someone upstream is already required to produce one for a different audience or a different distribution channel, and the same file gets reused on YouTube. An independent creator with no such obligation captions a video only if they choose to, or leaves it to whatever YouTube's own automatic system manages, which is exactly why caption quality across the platform is so inconsistent.

Scale is part of why this matters. RNID estimates that over 18 million people in the UK alone are deaf, have hearing loss or tinnitus. Its long-running Subtitle It! campaign reported that 80% of regulated UK on-demand services provided no subtitles when the campaign launched, against 94.7% providing them by 2024, a shift the organisation attributes largely to sustained campaigning rather than to law on its own.

Accessibility law reads like a checklist until you remember what a checkbox stands for. Over 18 million people in the UK are deaf, have hearing loss or tinnitus. WCAG 1.2.2 exists because a caption track is not optional for them.

YouTubeScribe, on reading WCAG for this page

The four kinds of extractor, and how to judge one

Free YouTube subtitle extractor: every method that still works separates the job into four routes to a file: paste a link, use YouTube's own panel, download by hand, or run speech recognition. This is a different split. It groups the tools themselves by what they are, which matters more once you start asking who can see your data while the job runs.

A web tool is a page you visit. You paste a link, a server somewhere fetches the track and hands you a file, and the page forgets about the job once your browser has the download. This is the shape YouTubeScribe takes, and it is the lowest-commitment option: no install, no account for a single free run, nothing left behind on your machine. A YouTube link can also take three different shapes, a share link, a watch page address, or an embed URL, and a decent web tool accepts all three without you needing to know which is which; How to get a transcript from a YouTube video covers that ground on its own. At real scale, the honest limitation of a web tool is server capacity rather than trust: a free tier will eventually throttle or queue very large batches, which is a fair trade for asking nothing of you upfront.

A browser extension installs itself into your browser and adds a button to the YouTube page itself. Convenient, because it lives exactly where you are already looking. The cost is permission scope: an extension capable of reading a video page can usually read every page you visit unless its manifest is narrowly scoped, and most people never check which is true of the one they installed. In Chrome's extension model specifically, a narrowly built tool can request access only to the tab you actively click it on, rather than blanket access to every site, and the difference between those two permission grants is visible in the install prompt if you read it before accepting.

An API script is code, yours or someone else's, calling the YouTube Data API's captions endpoints directly. The list method is broadly available with a plain API key. The download method needs OAuth and, per Google's own documentation, is scoped to captions you own or where the owner has granted third-party access, on top of a 200-unit quota cost per call against your daily allowance. This is the route for someone building a pipeline, not for someone downloading five files. It suits a developer who already has a Google Cloud account and does not mind an afternoon of setup once, in exchange for a route that never depends on a third party's server being up.

A desktop app is software you install and run locally, no server in the loop at all once it is installed. Nothing you paste ever leaves your machine, which is the strongest privacy story of the four, provided you trust the publisher enough to run their binary in the first place. That is not a small proviso. An unsigned executable from an unknown source asks for more trust than any web page does, since a bad web page can only fail at its one job while a bad program can do far more. This is also where offline transcription tools for track-less videos tend to live, since running speech recognition locally avoids sending audio to anyone else's server, at the cost of needing real processing power on your own machine.

None of these four is inherently the right choice. They trade different things for different jobs, and the trade is rarely about accuracy, since an honest tool of any of the four shapes reads the same file as the other three. It is about who else sees your link, what happens to it after the job finishes, and how much you have to install or set up before the first file lands. Before you paste anything into any of them, run through a short checklist:

• Does it need your YouTube password or an OAuth login, or does a public link work on its own. A free single-transcript job on a public video should never need your credentials.
• Does it log the links you paste, and does it say so anywhere. Silence on this question is itself an answer.
• Does it keep a copy of the output on its own server after handing it to you, or does it forget the job once your download starts.
• For a browser extension, what permissions does the install prompt actually list. Read and change data on every site you visit is a broad grant for a job that only needs one video page.
• For an API script, whose credentials are doing the asking, yours, or a shared key sitting in someone else's server that you have no visibility into.
• For a desktop app, is the publisher identifiable and the binary signed, or is it an anonymous download from a forum post.
• Does the tool tell you plainly when a video has no caption track, or does it hand back a transcript for every link regardless, which is the strongest sign it is inventing rather than reading.

For a single public video, most of this barely matters: paste the link into any tool that does not ask for your password, and move on. The checklist earns its keep once the job repeats, a script running nightly against a channel, a browser habit formed over months, a colleague asking which tool the whole team should standardise on. Scale is what turns a one-off convenience into a standing decision about whose server sees your links.

How accurate is a free extractor, really

Two kinds of caption track live on YouTube: one written by a person, one written by speech recognition software the moment the video finished processing. How YouTube captions actually work goes into the anatomy of both. What matters here is simpler: which kind of track a video has decides its accuracy ceiling before any extractor gets involved.

Every free extractor, YouTubeScribe included, reads the identical file YouTube already stores. Nothing about how quickly a tool responds, how polished its interface looks, or how many features it bundles changes a single word inside that file. Ten extractors pointed at the same automatic track will return ten identical transcripts of the same errors, because none of them are writing anything, they are all copying.

Accuracy itself is not one number. A track can be accurate at the word level, meaning the individual words are mostly right, while still failing at the phrase level, meaning the meaning of a sentence is wrong even though most of the words in it are technically correct. Punctuation and speaker attribution add a third axis entirely: a transcript with every word correct but no full stops or speaker labels can still be nearly unusable for someone building a dataset or checking a formal quote. Any accuracy claim worth trusting says which of these it is measuring.

Plenty of pages throw around a rounded accuracy percentage for automatic captions without saying where the number came from. One of the few studies that actually measured this rather than repeating folklore is Bryan Parton's 2016 paper, Video Captions for Online Courses: Do YouTube's Auto-generated Captions Meet Deaf Students' Needs?, published in the Journal of Open, Flexible and Distance Learning. The study examined YouTube's auto-generated captions on course video from the specific angle of whether they serve deaf students, and it counted rather than estimated: across 68 minutes of auto-captioned video, it recorded 525 phrase-level errors, an average of 7.7 errors per minute.

A phrase-level error is not a stray typo. It is a mistake that changes or removes a chunk of meaning, a wrong word standing in for the right one, a dropped clause, a name rendered as something else entirely. For someone relying on the caption text as the record of what was said, a deaf viewer, a researcher building a dataset, a journalist checking a quote, 7.7 of those a minute is not a rounding issue. It is frequent enough to plan around rather than to shrug off. It is also a single study with a specific sample, not an industry-wide census, and it should be read as one careful data point rather than as the final word on automatic caption quality generally.

This is also why comparing extractors on accuracy is close to meaningless. If two tools return different text for the same video, one of them is probably not reading the real track. It may be running its own speech recognition and presenting that as extraction, or it may be serving a cached copy of an older, since-corrected file. Either way, the honest comparison is not which extractor is more accurate, it is which track this particular video has, and whether the tool you used actually read it.

What paying for a tool actually buys you

If accuracy is fixed by the track, it is worth asking what a paid tier of any extractor is actually selling. Not better words. What money buys is usually speed at scale, more output formats, batch and playlist handling, or a support inbox that answers when something breaks. On YouTubeScribe specifically, the free tier already returns the same words a Pro run would, because the underlying read is identical; Pro adds format options such as VTT and higher volume rather than a cleaner transcript. Any tool that implies a paid tier reads captions more accurately is selling something that is not really for sale.

Subtitles in other languages, and the dubbing confusion

YouTube's automatic captioning listens in roughly 70 languages, per its own Translation and transcription glossary. Separately, YouTube can auto-translate an existing track into many more languages on the fly, producing a translated text track generated from whichever original track already exists. Those are two different jobs with two different reach.

Then there is the confusion that trips up almost everyone at some point. YouTube's automatic dubbing feature translates and re-voices a video into another language. Per YouTube Help's own Use automatic dubbing page, what it produces is a new audio track played alongside the original video, not a text file. Go looking for an SRT of the Spanish dub and there usually is not one, because dubbing never wrote text at all. It gave the video a voice, not a transcript.

The practical fix is to check both lists separately. Open the language menu inside the video's caption or transcript panel, and count the caption tracks on offer. Then check the audio track menu, usually a separate control, for dubbed languages. They are rarely the same list, and assuming they match is where most disappointment in this area comes from.

The standards underneath the file

Three formats sit underneath almost everything discussed on this page, and a fourth, plain SRT, sits alongside them without ever being formally standardised. SRT vs VTT vs TXT: which subtitle format to use covers the practical side of picking and converting between them for your own project. Here the question is different: where do these formats come from, and why do so many of them exist at all.

SRT itself is the odd one out in this list, because it was never standardised by any of the bodies that publish the others. It comes from SubRip, ripping software from the early 2000s, and its format spread by everyone copying what already worked rather than by a specification document. That informal history is exactly why it is also the most forgiving format in practice: there was never a strict body to please, only other software to stay compatible with.

WebVTT is a W3C specification, not just a file shape people copied from SRT. It is the format the HTML track element expects natively in a browser, which is why it is the one most tied to the modern web platform specifically, rather than to broadcast or professional subtitling pipelines.

Timed Text Markup Language 2, a W3C Recommendation published 8 November 2018, is XML-based rather than the plain-line format SRT and VTT use. It supports far richer styling and positioning: font, colour, region layout, and metadata that plain cue formats have no room for. It shows up less in casual subtitle work and more in professional captioning pipelines and platforms that need to preserve exact visual presentation across languages.

EBU-TT Part 1, documented in the European Broadcasting Union's TECH 3350, is a TTML profile built specifically for European broadcasters. It narrows TTML2's very wide feature set down to what broadcast subtitling actually needs, which makes it interoperable across national broadcasters in a way that full TTML2, with all its optional features, is not. If a subtitle file you receive carries the EBU-TT namespace, it came out of, or is heading into, a broadcast workflow rather than a casual download.

Recognising which family a file belongs to is a genuinely useful skill even if you never touch broadcast work. A plain-line file with a comma in its timestamps is SRT. The same shape with WEBVTT on the first line and a full stop instead is WebVTT. Angle brackets and a tt namespace declaration mean TTML2 or an EBU-TT profile of it, and that file is unlikely to open cleanly in a tool built only for the first two.

Together these form a rough hierarchy: SRT for portability, WebVTT for the browser, TTML2 for full styling control, EBU-TT for broadcast interoperability across Europe. An extractor's job is to hand you the one your video already has, or to convert it into the one you actually need for your own workflow.

Who uses this, and what they use it for

Five groups show up constantly in our support inbox and in what people build against the tool. Same file, five different jobs.

• Researchers. Qualitative work that studies what was said rather than just what was filmed, discourse analysis, coding interview transcripts, building a corpus for computational linguistics. A caption file gives them searchable, timestamped text without paying for professional transcription on every source video.
• Journalists. Checking a quote against the exact words a public figure used, timestamping when something was said inside a long press conference or livestream, and pulling text fast enough to file before a deadline closes.
• Developers. Building the extraction step into something bigger, a search index across a channel's back catalogue, a summarisation pipeline, an accessibility layer bolted onto another product. This group is the one most likely to hit the YouTube Data API's captions endpoints directly rather than use a paste-a-link tool.
• Marketers and content teams. Repurposing a video into blog posts, social captions and show notes, or researching what a competitor actually says in their own videos rather than guessing from titles and thumbnails.
• Students. Reviewing a lecture at reading speed instead of playback speed, searching a long recorded class for the one section that covers an exam topic, or simply needing text because audio alone is not accessible to them.

None of these five groups is mutually exclusive with the others, and the same person often moves between roles inside one project: a developer wiring the API into an internal tool for a marketing team that will use the output the way a student uses lecture notes. The tool underneath does not know or care which hat you are wearing. The job is the same file transfer either way.

A rough 48 hour version of this, if you are starting from nothing and need a small batch of transcripts to actually work with:

1. Day one, morning. List the videos you actually need and check each one for a caption track using the CC button or the transcript panel, so you are not surprised by misses later.
2. Day one, early afternoon. Paste links one at a time if the list runs to a handful, or queue a playlist or channel URL if it runs to dozens; How to get a transcript from a YouTube playlist covers the bulk route in full.
3. Day one, late afternoon. Skim what came back. Flag anything auto-generated that looks rough, and note any misses to chase separately, whether that means asking a creator or accepting the video has no track.
4. Day two, morning. Do the actual work the text was for: quote-checking, coding transcripts, building a search index, or drafting copy. If the goal is an article rather than a research file, How to turn a YouTube video into a blog post covers that specific conversion.
5. Day two, afternoon. File the sources. Keep the original SRT even after pulling what you needed from it, since re-deriving timing later is far slower than keeping the file you already have.

The short version of all of this: a free YouTube subtitle extractor is a copier, not a magician, and once you know that, most of the confusing bits stop being confusing. The law increasingly expects captions to exist at all, which is why so many videos have them. The tool you pick changes what it costs you in trust, not in accuracy, because every honest extractor reads the same file. The number that actually describes quality is a property of the track, not the download, and the Parton study is the clearest evidence of that gap in the open literature. Standards multiply because broadcast, web and casual use never needed the same file. And the people running this at scale are not doing anything exotic: researchers, journalists, developers, marketers and students, mostly reaching for the same paste-a-link tool this whole site is built around.

Questions people ask

Sources

1. W3C WAI. Understanding SC 1.2.2 Captions (Prerecorded). w3.org· Checked 19 August 2026.
2. W3C WAI. Understanding SC 1.2.4 Captions (Live). w3.org· Checked 19 August 2026.
3. ADA.gov. Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments. ada.gov· Checked 19 August 2026.
4. Section508.gov. Captions and Transcripts. section508.gov· Checked 19 August 2026.
5. FCC. Closed Captioning of Video Programming Delivered Using Internet Protocol. fcc.gov· Checked 19 August 2026.
6. FCC. 21st Century Communications and Video Accessibility Act (CVAA). fcc.gov· Checked 19 August 2026.
7. legislation.gov.uk. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. legislation.gov.uk· Checked 19 August 2026.
8. EUR-Lex. Directive (EU) 2019/882 (European Accessibility Act). eur-lex.europa.eu· Checked 19 August 2026.
9. W3C. Timed Text Markup Language 2 (TTML2). w3.org· Checked 19 August 2026.
10. EBU. TECH 3350: EBU-TT Part 1 Subtitling Format Definition. tech.ebu.ch· Checked 19 August 2026.
11. Google for Developers. YouTube Data API: Captions: download. developers.google.com· Checked 19 August 2026.
12. YouTube Help. Translation and transcription glossary. support.google.com· Checked 19 August 2026.
13. YouTube Help. Use automatic dubbing. support.google.com· Checked 19 August 2026.
14. RNID. 10 years of Subtitle It! creating change together. rnid.org.uk· Checked 19 August 2026.
15. RNID. Prevalence of deafness and hearing loss. rnid.org.uk· Checked 19 August 2026.
16. Parton, B. S. (2016). Video Captions for Online Courses: Do YouTube's Auto-generated Captions Meet Deaf Students' Needs? Journal of Open, Flexible and Distance Learning 20(1), 8-18. jofdl.nz· Checked 19 August 2026.
17. YouTube Help. Use automatic captioning. support.google.com· Checked 17 August 2026.
18. YouTube Help. Supported subtitle and caption files. support.google.com· Checked 17 August 2026.
19. YouTube Help. Add subtitles and captions. support.google.com· Checked 17 August 2026.
20. W3C. WebVTT: The Web Video Text Tracks Format. w3.org· Checked 17 August 2026.
21. Google for Developers. YouTube Data API: Captions. developers.google.com· Checked 17 August 2026.

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