yt-dlp 403 Forbidden: Why It Happens and How to Fix It

If you've run yt-dlp and hit this:

ERROR: unable to download video data: HTTP Error 403: Forbidden

…you've run into YouTube's anti-bot defenses. A 403 Forbidden means the server understood your request and refused it — the download URL yt-dlp extracted was rejected before any video data came back. It's one of the most common yt-dlp errors, and it almost never means your command is wrong.

This guide covers why it happens and every fix that actually works, roughly in order of how often it resolves the problem.

Why yt-dlp returns 403 Forbidden

YouTube constantly changes how it signs and serves media URLs, specifically to break automated downloaders. A 403 usually comes down to one of these:

• Your yt-dlp is out of date. YouTube shipped a change and the extractor hasn't caught up in your installed version.
• The stream URL was signed for a different client/IP. YouTube ties the media URL to the session that requested it; a mismatch gets rejected.
• You're being rate-limited or bot-flagged. Too many requests from one IP — common on servers, CI, and cloud hosts — trips detection.
• The video needs authentication (age-restricted, members-only, or region-locked) and you're requesting it anonymously.

Fix 1: Update yt-dlp (fixes most cases)

The single most common cause is a stale binary. YouTube breaks extractors regularly and the maintainers patch them fast — but only new versions get the fix.

yt-dlp -U

Then confirm you're actually on the latest release:

yt-dlp --version

Re-run your command. If the 403 is gone, you're done. If not, keep going.

Fix 2: Pass your browser cookies

When YouTube wants a signed-in session, exporting your browser cookies makes yt-dlp look like a logged-in user:

yt-dlp --cookies-from-browser chrome "https://www.youtube.com/watch?v=VIDEO_ID"

Swap chrome for firefox, edge, safari, or brave. For headless servers where no browser exists, export a cookies.txt on a normal machine and pass it explicitly:

yt-dlp --cookies cookies.txt "https://www.youtube.com/watch?v=VIDEO_ID"

Fix 3: Force a different player client

YouTube serves different signed URLs to different clients. Forcing the android or ios client sometimes yields a URL that isn't 403'd:

yt-dlp --extractor-args "youtube:player_client=android" "https://www.youtube.com/watch?v=VIDEO_ID"

This changes often as YouTube adjusts which clients it trusts — treat it as a workaround, not a permanent fix.

Fix 4: Slow down and reduce concurrency

If you're downloading in bulk, you're likely being rate-limited. Back off:

yt-dlp --limit-rate 2M --sleep-requests 2 --sleep-interval 5 --max-sleep-interval 15 \
  "https://www.youtube.com/watch?v=VIDEO_ID"

--sleep-requests spaces out API calls; --sleep-interval/--max-sleep-interval add randomized pauses between downloads. This won't help a single failing video, but it's essential at scale.

Fix 5: Get off flagged IPs

Datacenter IP ranges (AWS, GCP, Azure, most VPS providers) are heavily bot-flagged, so the same command that works on your laptop 403s on a server. Options:

• Route through residential proxies with --proxy (adds cost and setup).
• Rotate IPs across requests.
• Move the workload somewhere with cleaner IP reputation.

yt-dlp --proxy "http://user:pass@residential-proxy:port" "https://www.youtube.com/watch?v=VIDEO_ID"

When the fixes stop scaling

Any one of these fixes a video on your own machine. The problem is that none of them stay fixed in production. Update yt-dlp today, and YouTube breaks it again in two weeks. Add cookies, and they expire. Move to a server, and the IP gets flagged. Teams that download YouTube programmatically end up maintaining a small, fragile infrastructure project — cookie rotation, proxy pools, yt-dlp version bumps — instead of shipping their product.

Quick reference

Frequently asked questions