We Benchmarked Three Ways to Get a YouTube Transcript: Home Connection vs Cloud Server

Three ways to get the transcript of a YouTube video: youtube-transcript-api (a free Python library), yt-dlp (a free command line tool), and our hosted API, used only through its public documentation. Each ran the way its own documentation recommends.

The 54 videos were chosen from 1,049 search results in a fixed order, in categories: English videos with manual captions (short, medium, long), English videos with automatic captions only, Spanish, Hindi, Japanese and German videos, Shorts, and edge cases (captions disabled, age-restricted, unavailable). They ran from two places: a home connection in India and a GitHub-hosted runner, which uses a cloud address.

On the 44 videos that have captions, all three methods mostly worked. Latency is for successful requests, and for the hosted API only for responses that were not served from its cache.

yt-dlp's five misses were all HTTP 429 errors on the subtitle download, concentrated in Shorts and long videos with automatic captions. The hosted API's median looks fine, but its slow tail is real: 11.8 seconds at the 95th percentile, against about 2 seconds for the library. It is not explained by video length, since a 42-second video took 12 seconds. We do not know why yet.

The same videos from a GitHub-hosted runner. A method that is blocked five times in a row stops, and its remaining videos are recorded as not attempted instead of being counted as failures.

This is the result that matters most if you run code on a server, a serverless function or a workflow tool: free tools that fetch directly from YouTube can fail from the first request when the address belongs to a cloud provider. The library says so in its own documentation.

• The library's score is partly circular. The caption labels used to choose the videos came from youtube-transcript-api itself. A video only entered a "has captions" category if the library could list its tracks. That favours the library and tells you nothing for or against the other two.
• One network per type, one day. Another home connection, country or week can look different, and not every cloud address is treated alike.
• Small sample. 54 videos support broad patterns. Treat gaps under about ten percentage points as noise.
• Cache. The hosted API caches transcripts. Its latency here counts uncached responses only (16 of 44 home responses and 8 of 43 cloud responses came from cache).
• We are one of the vendors. That is why the video list was frozen first, every failure is counted, and all of it is public so you can find our mistakes.

• For a few videos from your own machine, the free tools work and cost nothing.
• On a server, plan for blocks: back off, cache what you fetch, and treat blocked requests differently from videos that have no transcript. Our errors guide sorts them.
• Language codes must match exactly in both free tools: a request for es misses a track coded es-ES, and yt-dlp then exits successfully without writing a file. Check that a file exists.
• If you would rather not own the blocking problem, a hosted service is one answer, including ours (compared without ranking in the tools roundup). Look at the tail and the failures, not only the median.

The first runs gave misleading numbers, and we found out by inspecting the failures. We ran yt-dlp without a JavaScript runtime, called the library with exact language codes, and assumed yt-dlp matched languages loosely when it does not. We fixed the setup, kept the earlier results marked as superseded, and wrote the order of events into the methodology. A run also froze for a day on a request with no timeout, and another stopped early for a reason we never found. Both are documented, and both were repeated.

Run it from your own network and send us the results. Tools, code, video list, raw data and methodology are in the repository. If we got something wrong about any tool, tell us there and we will correct it.