Why does yt-dlp return HTTP Error 403: Forbidden on YouTube?

Three different things produce the same line. YouTube's bot check rejected an anonymous or stale session (fix: pass fresh browser cookies). yt-dlp had no JavaScript runtime, so it could not solve the n-signature challenge and the stream URLs it built were rejected by googlevideo (fix: install Node.js or Deno). Or the cookies you passed made yt-dlp skip the player clients that do not need a token, leaving only clients that need the challenge solved (fix: drop the cookies for that download).

Does --cookies-from-browser always fix the 403?

No. It fixes the bot-check 403. It does nothing for the missing-runtime 403, and on YouTube it can cause a third kind: with any cookie present yt-dlp skips the android_vr, tv_simply and ios clients, which are the ones that work without a PO token. If cookies made it worse, retry the same URL without them.

Do I need Node.js for yt-dlp?

For YouTube in 2026, effectively yes: yt-dlp needs a JavaScript runtime (Node.js or Deno on your PATH) to solve the n-signature challenge. Without one, some formats go missing or download as HTTP 403. yt-dlp prints a warning about this, but it is easy to miss under the error.

Fix yt-dlp HTTP Error 403: Forbidden on YouTube (2026)

The error looks like this:

ERROR: [youtube] aBcDeFgHiJk: Unable to download video data: HTTP Error 403: Forbidden

I maintain a desktop app that wraps yt-dlp, so I see this error in bug reports every week. The reason it is confusing is that three different problems print the same line, and the popular fix (--cookies-from-browser) solves only one of them and can actively cause another. Here is how to tell them apart.

Cause 1: YouTube’s bot check rejected your session

YouTube rejects requests that look automated: no cookies, a datacenter IP, or a session it does not trust. The stream request is refused with a 403.

Fix: pass your real browser session so the request looks like one of your own tabs.

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

Replace chrome with firefox, edge, brave or safari. Two practical catches:

On macOS, reading Chrome’s cookie store triggers a Keychain permission prompt. Grant it once; if you decline, yt-dlp silently runs without cookies.
On Windows, recent Chrome versions encrypt the cookie database so that yt-dlp cannot read it. Use Firefox for the cookie export, or export a cookies.txt with a browser extension and pass --cookies cookies.txt.

If the 403 came from a members-only or age-gated video, this is your cause and this is the whole fix.

Cause 2: no JavaScript runtime, so the challenge never gets solved

YouTube protects its stream URLs with an “n-signature” challenge. yt-dlp solves it by running a small piece of JavaScript, which means it needs a JS runtime on your machine. Without one, yt-dlp still produces a stream URL, but an unsigned one, and googlevideo rejects it with a 403. Cookies do not help here at all.

yt-dlp prints a warning about the missing runtime, but it scrolls past above the red error and most people never see it.

Fix: install Node.js or Deno and make sure it is on your PATH. Then run the same command again. If you are on the yt-dlp-bundled app route described below, the app detects a runtime for you.

Cause 3: the cookies themselves are the problem

This one is counter-intuitive and I only confirmed it by reproducing it. When you pass cookies, yt-dlp skips every YouTube player client that cannot carry them. Look for lines like:

Skipping client "android_vr" since it does not support cookies

Those skipped clients (android_vr, tv_simply, ios) are exactly the ones that work without a PO token. The clients that remain hand back URLs that need the challenge from Cause 2 solved, so on a machine without a runtime the download fails. I verified this on 2026-07-28: identical options returned 403 with a cookie file and downloaded fine without one.

Fix: retry the same URL without --cookies-from-browser. If it works, keep cookies for the videos that need them (members-only, age-gated) and go anonymous for everything else.

The order to try things in

Run without cookies. If it works, you were in Cause 3.
Still 403? Check for a “JavaScript runtime” warning in the output. Install Node.js or Deno if you see it (Cause 2).
Still 403, or the video is members-only? Add --cookies-from-browser (Cause 1).
Update yt-dlp (yt-dlp -U). YouTube changes its player often and the fix is frequently already released.

Doing this automatically

ViralMint is a free, open-source desktop app for Mac, Windows and Linux that bundles yt-dlp and runs this exact ladder for you. On a 403 it first refreshes the browser cookie jar, then retries the download with cookies removed, so both Cause 1 and Cause 3 are covered without typing a flag. For Cause 2 it looks for Node.js or Deno on your machine and, if it finds neither, uses the portable Node that its optional Motion Graphics plugin installs. Everything runs locally; your cookies never leave your computer.

The same app then transcribes the download with local Whisper and can clip it into shorts, which is the workflow it exists for. Paste the URL, and the download either succeeds or tells you plainly which of the three causes it could not get past.

Will the 403 come back?

Yes, periodically. YouTube changes the player and its bot checks, and yt-dlp ships a fix within days. When a download that worked last week fails today, update yt-dlp first; when the error persists after updating, walk the three causes above in order.