Short version: the library is fine and you did not break it. YouTube blocks IPs owned by AWS, Google Cloud, and Azure, so code that runs on your laptop throws RequestBlocked or IpBlocked as soon as you deploy. You have two fixes: rent rotating residential proxies, or call a hosted API. On raw bandwidth they cost about the same, and at low volume the proxies win. The section on cost below shows the math.
To test one video right now, paste its URL into the free transcript tool. No signup, no card.
What breaks
youtube-transcript-api by Jonas Depoix is good, free software. It is MIT licensed, needs no API key, reads auto-generated captions, and runs no browser, so it fits in a Lambda. If it stopped working, the library did not change. YouTube did.
From the README, under “Working around IP bans”:
“Unfortunately, YouTube has started blocking most IPs that are known to belong to cloud providers (like AWS, Google Cloud Platform, Azure, etc.), which means you will most likely run intoRequestBlockedorIpBlockedexceptions when deploying your code to any cloud solutions.”
YouTube sorts traffic by who owns the IP. Data center IPs get blocked. Home IPs mostly do not. Your laptop has a home IP and your server does not. That explains the odd pattern:
- Works on your machine, every time.
- Fails on Lambda, EC2, Cloud Run, App Engine, Azure Functions, Vercel, Render, and Fly.
- Works again through a home VPN.
- Comes back when you deploy to a new region, then dies again.
You will see RequestBlocked when YouTube refuses the call and IpBlocked when your IP is on the list. The library also raises NoTranscriptFound when the languages you asked for are missing, VideoUnavailable for deleted or private videos, and AgeRestricted for age-gated ones it cannot log in to.
The trap: a TranscriptsDisabled that is not
This is where people lose a day. When you are blocked, YouTube’s reply looks the same as “this video has no captions.” So the library raises TranscriptsDisabled for a video whose captions you can see in your browser.
Issue #303 says it in the title: “TranscriptsDisabled But it’s not disabled (works locally, fails on Cloud machine).” Opened July 2024, it ran to 187 comments. People show up sure they found a parser bug and leave knowing they were blocked. It came up again in #511 (August 2025) and #593 (May 2026). All three are closed now.
Quick test: run the same video ID on your laptop. If it works there and fails on your server, captions are not the problem.
The two fixes
The README points at the first one. Route the library through rotating residential proxies. Proxy support is built in, with Webshare wired up already:
from youtube_transcript_api import YouTubeTranscriptApi
from youtube_transcript_api.proxies import WebshareProxyConfig
ytt_api = YouTubeTranscriptApi(
proxy_config=WebshareProxyConfig(
proxy_username="...",
proxy_password="...",
)
)Use GenericProxyConfig for any other provider. Buy the right product, though: the README says YouTube “will ban static proxies after extended use,” and tells you to get Webshare’s “Residential” package rather than “Proxy Server” or “Static Residential.” The cheap data center tier just buys back the problem you already have.
The second fix is to call an API that already runs the proxies. One GET with a key, and you get the transcript text, an is_auto_generated flag, and a metadata object with the title, channel, and duration:
import requests
r = requests.get(
f"https://tapline.sh/api/v1/youtube/videos/{video_id}/subtitles",
headers={"X-API-Key": API_KEY},
timeout=30,
)
transcript = r.json()["transcript"]Same job either way. The difference is what you pay for and what you maintain, which is the next section.
One aside if your plan B was yt-dlp --write-auto-subs. It hits a different wall: PO Tokens, short for Proof of Origin. The PO Token guide covers the fixes, which are plugins or your browser cookies. On a cloud IP you now have two problems to solve, not one.
What the data actually costs
Proxies bill per gigabyte, so the first thing to know is how many bytes a transcript moves. More than you would guess. To read captions the library first pulls the whole YouTube watch page to find the caption track, then fetches the captions themselves. That watch page is the expensive part.
Measured on 2026-07-27, a watch page is 128 to 144 KB gzipped, which is what a proxy meters. Call it 150 KB per transcript with the caption fetch added. That works out to about 6,700 transcripts per GB, so 1,000 transcripts move roughly 0.15 GB.
Rotating residential proxies run about $1.50 per GB on a committed terabyte and $6 to $8 per GB at entry or pay-as-you-go rates. Multiply it out and both paths land in the same place:
| Transcripts/mo | Traffic | Proxies, bandwidth only | Tapline |
|---|---|---|---|
| 5,000 | 0.75 GB | $3 to $6 | Starter, $49 |
| 50,000 | 7.5 GB | $26 to $45 | Starter, $49 |
| 500,000 | 75 GB | $169 to $300 | Growth, $199 |
| 2,000,000 | 300 GB | $450 to $750 | Pro, $499 |
The proxies win on price at small volume, and it is close to a wash from about half a million transcripts up. Per 1,000 transcripts, proxies cost roughly $0.20 to $1.20 in traffic and Tapline costs $0.25 to $0.98. Anyone telling you a hosted API is ten times cheaper is selling you something.
One thing the table flatters: proxy plans are prepaid buckets, so you buy the tier, not the usage. At 5,000 transcripts a month you still pay whatever the smallest plan costs, and unused gigabytes on most plans do not roll over. Size the bucket to your worst month, not your average one.
What the proxy column leaves out
That column is bandwidth and nothing else. The rest of the bill is real, and it is where the two paths separate:
- Blocked calls still cost you. YouTube sends back a page, you pay for those bytes, and you got no transcript.
- Retries multiply the bill. Every retry is another watch page.
- You build and keep the rotation, the retry logic, and the failure handling.
- You lose a day each time YouTube changes something.
The block rate is the number that decides it. At a 10% block rate you are buying 10% more bandwidth for nothing. At 50%, the proxy column doubles and the comparison flips. Tapline charges 0 credits for a failed call, so a block costs you nothing but the wait.
Run your own numbers before you take ours. Pull a transcript for the video that keeps failing, or send a live request and read the JSON.
When to keep the free library
- You run it locally. A laptop, a desktop app, a script on your own machine. Nothing is blocking you, so do not pay.
- Your volume is low. A few hundred a month, and a retry tomorrow is fine. Free beats every paid plan here.
- Your host is not blocked. Some school and office networks do not count as data centers. If it works, it works.
- You can live with failures. Batch jobs that retry for days, or internal tools where a bad afternoon costs nothing.
- You need captions translated. The library does this on its own. That is a real thing to give up.
- You already run proxies. If you have the pool and the retry code working, the bandwidth is cheap. Keep it.
When to move
- Production SaaS in the cloud. This is the case the README warns about. Retries do not fix a blocked IP range.
- Serverless. Lambda, Cloud Functions, Vercel. The ranges are blocked and you cannot pin an IP.
- Someone is waiting on the answer. “Blocked, try later” is not a screen you can show a user.
- Your block rate is high. Bandwidth you spend on blocked calls buys you nothing. That is the number that moves the math.
- You need more than transcripts. Comments, search, heatmaps, formats. The library does none of it, and four scrapers means four things to fix.
- You are tired of the breakage. Blocked IPs, PO tokens, bot checks. It comes around every few months and costs you a day each time.
Most people who install this library never need to pay anyone. If the left column is you, keep your money.
Migration
The output shapes differ, so give it an afternoon. You also do not have to move all of it. Keep the library as your default and call the API only when you get RequestBlocked or IpBlocked. Failed calls cost 0 credits, so that path only bills when it returns a transcript, and you keep the cheap bandwidth for the calls that work.
- Sign up for 500 free credits. No card. That is about 250 transcripts, enough to run part of your backlog through both paths.
- Diff the output. You get a transcript string,
is_auto_generated, and ametadataobject. Fix your parser once. - Measure your block rate first. It decides the whole comparison. If almost nothing is blocked, stay where you are.
- Keep the library for local work. Plenty of teams run the library in dev and the API in prod.
The full endpoint list is in the YouTube docs.
FAQ
Why does youtube-transcript-api work locally but fail on my server?
Because YouTube blocks IPs owned by cloud providers. The library's README says YouTube blocks most IPs known to belong to AWS, Google Cloud Platform, Azure and the like, which gives you RequestBlocked or IpBlocked when you deploy. Your laptop has a home IP. Your server does not.
How do I fix "YouTube is blocking requests from your IP"?
Two options. Send the library through rotating residential proxies, which it supports with WebshareProxyConfig and GenericProxyConfig, or call a hosted API that handles blocks for you. Static and data center proxies do not last: the README warns that YouTube bans static proxies after extended use.
Why do I get TranscriptsDisabled for a video that clearly has captions?
Almost always because you are blocked, not because captions are off. When YouTube blocks a request, the reply looks the same as a video with no captions, so the library raises TranscriptsDisabled. Issue #303 ran to 187 comments on this one point. Run the same video ID on your laptop. If it works there and fails on your server, you are blocked.
Does youtube-transcript-api work on AWS Lambda?
Not reliably without proxies. AWS ranges are among the cloud IPs YouTube blocks, and Lambda gives you no way to pin a home IP.
Is youtube-transcript-api still maintained?
Yes. Version 1.2.4, MIT licensed, about 7,960 GitHub stars, last commit May 2026. The blocking is not a maintenance problem. It starts at YouTube, and no library can fix it from the client. As of 2026-07-27.
Is a paid transcript API cheaper than running proxies?
Often not, on bandwidth alone. A transcript moves about 150 KB through the proxy, because the library pulls the full YouTube watch page before the captions. At $1.50 to $8 per GB for rotating residential proxies, 1,000 transcripts cost roughly $0.20 to $1.20 in traffic, against $0.25 to $0.98 per 1,000 on Tapline plans. Proxies win at low volume. The gap opens once you count blocked calls, which still burn bandwidth and return nothing, plus retries, prepaid gigabytes you do not use, and the time you spend keeping it running. As of 2026-07-27.
Can I keep using the library and only pay for what fails?
Yes, and some teams do just that: try the library first, then call a hosted API when you get RequestBlocked or IpBlocked. Failed API calls cost 0 credits, so that path only bills when it returns a transcript.
From the repository and PyPI on 2026-07-27: version 1.2.4, MIT licensed, 7,960 stars, last commit May 2026. The quote comes from the README section “Working around IP bans.” Issue titles, dates, and comment counts came from the GitHub API the same day. Transfer sizes are our own measurement of three YouTube watch pages fetched with gzip on that date, and they vary with video length and caption size, so measure your own before you commit to a plan. Proxy rates move often and drop with commitment. Tapline publishes this page and sells a YouTube transcript API, so we compete with the do-it-yourself route. youtube-transcript-api is independent MIT software with no link to Tapline, and the list above says where it is still the better pick. Tapline is not affiliated with, endorsed by, or sponsored by YouTube.