GeezerVison

• Videos: 500 YouTube videos, 25 from each of 20 keyword searches taken in turn (the 12 searches of our Supadata benchmark plus 8 more: tutorials, podcasts, lectures, news, reviews, cooking, finance, music lessons and more, in English, French, Spanish and German). The searches asked for videos with captions. Nothing was picked or dropped based on how either API handled it.
• For each URL both APIs were called at the same instant, one URL at a time, from the same server (Warrenton Virginia US / AS16276 OVH SAS). Each request had 5 minutes to finish. There were no retries on either side, even though TranscriptAPI's documentation calls its 408 errors safe to retry.
• TranscriptFetch: POST /api/v2/transcripts/video with captions-only mode. TranscriptAPI: GET /api/v2/youtube/transcript, without a language, so each returned English or the video's first language.
• Our side bypassed our own cache, so every TranscriptFetch answer was a fresh fetch. TranscriptAPI answered 70% of its transcripts from its cache and labelled each one, which the split above uses.
• Network: 5 idle round trips from the same server: transcriptapi.com/api/v2/youtube/info (an unauthenticated request it rejects at once) 119-145 ms, transcriptfetch.com/api/v2/health 63-235 ms.
• The first video ran on its own as a check that TranscriptAPI's responses were read correctly; the rest followed with the same script.

Left out

• The 171 URLs of our earlier benchmark run were excluded when the corpus was built, so none of the 500 had been sent to either API by us before.

This is one night, one server and requests in sequence, run by one of the two vendors. Our own cache was switched off for the test; a normal TranscriptFetch client also gets cached answers for videos requested before, which this test did not measure. The next section shows how to rerun everything from your own machine.

Rerun it yourself

The script, all 500 URLs and every raw measurement are public. It needs only Node.js and your own API keys, so you can check these numbers from your own machine, region and plan.

When it has the video in its cache, yes: in our 29 September 2026 test its cached answers had a median of 0.3 s against our fresh fetch of 0.7 s, and 70% of its transcripts came from its cache. When it had to fetch the video, TranscriptFetch was 3x faster (0.8 s against 2.6 s), and our slowest 10% started at 1.1 s against its 3.0 s.

Only for videos other people have already requested. A cache cannot hold every YouTube video, so the more varied or niche your videos, the more often it misses. In our test it answered 100% of machine-learning explainers and 96% of university lectures from its cache, but 14% of faucet-repair videos, 14% of phone reviews and 0% of this week's Spanish news. It was under 50% on 5 of our 20 searches, and those searches produced 22 of its 37 failures. On a miss it answered in a median of 2.6 s against our 0.8 s.

It returned 463 of 500 against our 500. 31 of its failures were HTTP 408 "Request failed, please retry", which its documentation attributes to temporary problems such as bot detection, and 6 were videos it reported as not found or unavailable. Neither API was retried, so each got one attempt per video.

From about 30,000 transcripts a month, yes: $64.50 against $78 at 50,000 and $229 against $378 at 250,000, counting top-ups on both sides and TranscriptAPI's annual plan. Up to about 25,000 a month TranscriptAPI costs less, for example $18 against $25 at 10,000.

No. It returns YouTube captions only and answers 404 for a video without them. TranscriptFetch transcribes the audio with AI in that case, at 1 credit per started 5 minutes of audio, unless you ask for captions only.

Yes. Every account gets 50 free credits with no card, and failed requests are never charged.