# YouTube Downloader — page copy

> Extracted from PR #32 (`feat/youtube-downloader`), `en.json → productPages.youtubeDownloader`.
> `en` is authoritative; es / pt-br / fr / ru / zh carry first-pass human translations.

## SEO / metadata

- **Title:** YouTube Downloader: reliable YouTube downloads via Massive Residential | Massive
- **Description:** Open-source async service that runs YouTube downloads through Massive Residential Proxies: bounded concurrency, strict sticky sessions, a fresh route on every retry, and per-attempt telemetry.
- **JSON-LD (`SoftwareSourceCode`) name:** Massive YouTube Downloader

## Nav / products menu

- **Label:** YouTube Downloader
- **Blurb:** Open-source async YouTube downloads over Massive Residential.

---

## Hero

**Tag:** Open Source · MIT

# Reliable YouTube downloads *at scale*

An open-source async service that runs yt-dlp through Massive Residential Proxies. It matters because at volume, YouTube throttles and blocks datacenter IPs and naive scripts until downloads simply stop working.

- **[View on GitHub]** → https://github.com/joinmassive/Youtube-downloader

---

## The problem

### Why direct download scripts fail at volume

Running yt-dlp straight against YouTube tends to break the same ways once the volume goes up. This service exists to avoid them.

01. **Unbounded concurrency** — A naive script opens as many connections as it has URLs. That overwhelms both the proxy pool and YouTube, so failures cascade instead of backing off.
02. **Sessions that time out mid-download** — sessionmode=flex rotates the route underneath a long download, so a large video times out partway through and the whole attempt is wasted.
03. **Retries that repeat the failure** — A plain retry reuses the same route that just failed, so the second attempt fails the same way, burning the attempt budget without changing anything.
04. **Invisible proxy errors** — When a proxy-side error is swallowed, the job just “failed” with no exit IP, country, or ASN to act on. You can't tell a bad route from a bad video.

---

## How it works

### The operating model

One job flows from the API to a bounded worker, through a strict Massive session, into yt-dlp, and out to storage. A failed attempt returns for a fresh route.

> **Diagram (`YoutubeFlow`):** `POST /video → Worker (bounded concurrency) → Massive (strict session) → yt-dlp (extract + download) → Storage (upload + webhook)`, with a **fresh route on retry** loop from yt-dlp back to Massive. See `youtube-flow.svg`.

---

## What the service gives you

### Built for reliable, observable downloads.

**Async job API** *(Async API)*
Queue a job with POST /video and poll it with GET /video/{id}. Downloading happens in the worker, not in the HTTP request, so the response returns right away.
- Explicit states: queued, running, uploading, completed, failed
- Inspect every attempt at GET /video/{id}/attempts; retry a terminal failure at POST /video/{id}/retry

**Bounded concurrency and leases** *(Bounded concurrency)*
A per-worker concurrency cap holds connections to a level your proxy and YouTube success rates can sustain, and worker leases track jobs in flight.
- Pick the cap from observed success rates; 30 is a useful load-test setting
- A crashed worker leaves a lease behind; an expired lease is recovered and requeued on restart

**Strict Massive sessions** *(Strict sessions)*
Every attempt gets a unique session ID with sessionmode=strict. A route error invalidates the session rather than persisting through failures.
- A new session ID per attempt means a fresh route on every retry
- The worker owns retries and backoff; yt-dlp internal retries are disabled

**yt-dlp Python API integration** *(yt-dlp Python API)*
The service drives yt-dlp through its Python API, so proxy credentials never pass through a child-process command line, source file, or shell history.

**Modern YouTube extraction** *(Modern extraction)*
A Deno JavaScript runtime and configurable YouTube player clients handle modern player extraction.
- YTDLP_JS_RUNTIME=deno with a configurable YTDLP_YOUTUBE_PLAYER_CLIENTS list

**Local or S3 storage** *(Storage)*
Write results to the local filesystem for development, or to S3 and S3-compatible buckets when the optional dependency and credentials are present.

**Per-attempt telemetry** *(Telemetry)*
Each attempt records its phase, timing, byte count, selected player clients, and error code. Credentials are never included.
- With capture enabled, records include Massive exit metadata: exit IP, country, timezone, and ASN

**Signed completion webhooks** *(Webhooks)*
Set a webhook URL on a job to receive terminal notifications. With a signing secret set, deliveries carry an HMAC-SHA256 signature header.

---

## Why Massive

### Real residential routes, not datacenter IPs

The service routes every attempt through Massive Residential Proxies, so YouTube sees organic local traffic from real consumer devices.

**Stat pills:**

| Glyph | Number | Label |
|---|---|---|
| latency-meter | <600ms | Response |
| success-sparkline | 99.8% | Success |
| uptime-bars | 99.9% | Uptime |
| globe-arc | 195+ | Countries |

**Enterprise cards:**

- **SOC 2 Type 1 audited** — Independent audit of security controls and operational integrity.
- **GDPR + CCPA compliant** — Full compliance with global data privacy regulations.
- **AppEsteem certified** — Independent review of SDK practices and consent mechanisms.
- **99.9% uptime SLA** — Backed by 24/7 monitoring and dedicated infrastructure.
- **Engineers who answer engineers** — Dedicated account manager. Technical support from the team that built it.
- **Full audit trail** — Every device opted in, every request logged. Passes security review.

---

## Final CTA

## Clone it. Run it. *Ship it.*

No signup, no gate. Point it at your own Massive Residential credentials and you're downloading in minutes. When your volume outgrows a test run, book a call and we'll help you size a plan.

- **[View on GitHub]** → https://github.com/joinmassive/Youtube-downloader
- **[Book a call]** → https://meetings.hubspot.com/chen-assayag/round-robin