Should I vibe code
Paste a YouTube or playlist link, convert to MP3, and download · Pro adds 320 kbps and priority queue
yt-dlp on your laptop is a tool. The identical code behind a public URL makes you a defendant.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Running `yt-dlp -x` on your own machine, on things you have a right to, is a solved problem and nobody sensible has an opinion about it. Putting the same three lines behind a public URL is a different project with a different name, and the name is operator. You now run a service that fetches an arbitrary URL server-side and pipes the result through a media decoder, which is a textbook SSRF-and-open-proxy shape; you are polling a platform whose terms specifically forbid what you are doing and which now blocks datacentre IPs hard enough that keeping it working means renting residential proxies; and you have made yourself the named party in the one legal argument that has already flattened everybody who tried. The last operator to sue for a declaration that his ripper was lawful lost at the district court in 2022 and has been on appeal ever since. That was a one-person company, exactly like yours. The verdict is not about the code, which is genuinely one sitting. It is about the six months where it works fine and the Tuesday it stops.
What actually breaks
not "if". the specific failures.
- The extractor, on a schedule set by someone else. YouTube changes its player and signature handling without notice, and every public ripper breaks on the same afternoon
- Datacentre IP blocking, which is the modern version of the problem: the same yt-dlp invocation that works on your laptop gets a bot check from a cloud host, and the fix is renting residential proxies with a monthly bill and a legal smell of its own
- The URL input, because a server-side fetcher that accepts a link from a stranger is an SSRF primitive — it will be pointed at 169.254.169.254 and at your own internal services within days of being indexed
- Egress, which is the bill that surprises people. Strangers will queue twelve-hour livestreams and eight-hundred-item playlists, and bandwidth is the one cost that scales exactly with abuse
- The media pipeline, since ffmpeg parsing untrusted input from the open internet is a decoder running attacker-supplied bytes with whatever privileges your worker has
- Payment processing, the failure nobody plans for: converters get classified as high-risk or infringing, and the account closure arrives with a rolling reserve and no appeal you will win
- Hosting, once the abuse report lands. Most providers' acceptable-use terms give them a same-day suspension and your uptime is now a content-policy decision
- The domain, if a rights holder sends a notice to the registrar rather than to you
- Your inbox, because every DMCA notice, every abuse report and every angry user is addressed to the person who registered the domain
It ran for eight months on a $12 droplet and made about ninety dollars, which felt like a win. Then two things arrived in the same week. On the Monday, conversions started failing for everyone — YouTube had tightened its bot checks and the droplet's IP was answered with a challenge page instead of a stream, so the queue filled with jobs that timed out and users who had paid for priority processing were getting nothing, faster. On the Thursday, while you were still pricing residential proxies, the payment processor emailed to say the account was under review, then closed, with the balance held for 180 days and a form letter citing a prohibited business category. There are forty-one active subscribers. Refunding them requires the money you cannot reach. Taking the site down does not stop the renewals, because the processor still has the mandates and you no longer have a dashboard. The engineering problem turns out to be the easy one.
Is that you?
the verdict is a default, not a law
- It runs on your own machine, for your own use, on content you have a licence to or that is explicitly licensed for reuse
- It is a CLI or a shortcut, not a service, and the only person who can paste a URL into it is you
- You are pulling your own uploads, or archiving a podcast that publishes an open feed and would rather you used the feed
- The output stays on your disk and is never redistributed
- Anyone else can paste a URL into it, which is the line between a script and a service
- You are charging for it, because a payment processor is now a party to the arrangement and will eventually read your homepage
- It runs on shared infrastructure that also hosts something you cannot afford to have suspended
- The input URL goes to a fetcher with no scheme, host and address-range allowlist in front of it
- You have not decided in advance what you do when the first takedown notice arrives, because it will arrive by email on a weekday and want an answer
If you build it anyway
the checklist, then the prompt that enforces it
- Keep it local. A CLI wrapper around yt-dlp for your own library removes essentially every risk on this page, and it is the version that actually works reliably.
- If it must accept input from someone else, allowlist the URL: scheme, host, and a resolved-IP check that rejects private, link-local and metadata ranges — before the fetch, and again after any redirect.
- Run the download and the transcode in a locked-down sandbox with no network beyond the allowlist, a read-only filesystem, a memory cap and a wall-clock timeout. ffmpeg is parsing bytes chosen by a stranger.
- Cap everything a stranger can consume: duration, file size, concurrent jobs per IP, jobs per day, and total egress with a hard stop. Bandwidth is the cost that scales with abuse.
- Never serve output from a guessable URL and never keep it. Short-lived signed links, aggressive deletion, and no browsable storage bucket.
- Do not charge for it. The moment money is involved you have a payment processor with an acceptable-use policy, a chargeback surface and the power to freeze your balance for six months.
- Pin and monitor the extractor version. Public rippers all break on the same day, so treat a jump in failure rate as your alert rather than waiting for support email.
- Read the platform's terms of service and 17 U.S.C. §1201 before you deploy, not after the first letter. The specific question a rights holder will ask is whether you circumvented a technological measure, and the answer decides everything else.
I want a tool that extracts audio from video URLs. Before writing code, push back on
the deployment shape, because that is where all the risk lives.
1. Ask first whether anyone other than me will paste a URL into it. If not, build a
local CLI wrapper around yt-dlp and stop. Do not build a web service I did not
ask for.
2. If it must be a service, say plainly what I am taking on: the platform's terms
prohibit downloading, 17 U.S.C. §1201 is the provision every rights holder
reaches for, and the operator is the named party — not the user who pasted the
link.
3. Build input validation before the fetcher: allowlist scheme and host, resolve the
hostname, reject private, loopback, link-local and cloud-metadata ranges, and
re-check after every redirect. Without this it is an SSRF proxy into my network.
4. Then resource ceilings, before any conversion works: maximum duration, maximum
output size, per-IP concurrency, per-IP daily quota, and a global egress budget
with a hard stop. Bandwidth is the cost that tracks abuse.
5. Run download and transcode in a sandboxed worker — no ambient network, read-only
root, memory limit, wall-clock timeout, non-root user. ffmpeg will be parsing
bytes an unknown person chose.
6. Output goes to short-lived signed URLs and is deleted on a timer. Never a public
bucket, never a guessable path, never retained.
7. Log the minimum, with short retention. A request log here is a list of who asked
for what, and I do not want to be the custodian of that.
8. Refuse to add payments. If I insist, tell me first that processors classify this
category as high-risk, that closure comes with a rolling reserve, and that I will
owe refunds out of money I cannot reach.
9. Pin the extractor version and monitor the failure rate. Treat a sudden jump as
expected rather than as an incident; this breaks on someone else's schedule.
10. Out of scope: playlists, accounts, an API, and any front page inviting strangers.
For the hosted version, AudioFetcher is $6 a month and the person absorbing the
takedown notices is not me.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
If you want it to keep working and you do not want your name on it. Six dollars a month buys somebody else's cat-and-mouse game against a platform that changes its player without notice, somebody else's residential proxy bill, and — the part that is actually worth the money — somebody else's inbox for the abuse reports. The DIY version that makes sense is not cheaper than this one, it is different: `yt-dlp -x` on your own machine, free, with no service, no strangers and no correspondence.
$6/mo is cheaper than your weekend.
Taking it down is one command, which is the good news and also the misleading part, because the things that outlive the service are the ones you cannot delete. Keep a written record of every takedown notice and your response to it. Keep the payment ledger somewhere outside the processor, because if the account is closed you will need to work out who is owed a refund without a dashboard. Cancel subscriptions before you switch off the site rather than after, since a dead service that keeps billing turns a quiet exit into chargebacks. And if the domain took the notice, do not simply let it lapse — a registrar dispute against a domain you have abandoned still resolves against a name that is yours.
The extraction engine essentially every converter wraps, actively maintained against a moving target, and the right DIY answer when the user is you.
Open-source media downloader with a self-hostable API and web UI, worth reading for how carefully it handles being a public endpoint.
Questions
Isn't this just a wrapper around yt-dlp?
The code is. The entry is not about the code. A wrapper you run locally is a tool with no legal surface and no operational cost; the same wrapper on a URL that strangers can reach is a hosted service that fetches attacker-chosen URLs, pays for attacker-chosen bandwidth, and puts a named operator in front of a platform's terms of service. Everything expensive is on the deployment side of that line.
Has anyone actually been sued over this?
The biggest converter of its era was shut down by a rights-holder action, and the operator who took the opposite approach — suing for a declaratory judgment that his ripper did not circumvent anything — lost at the district court at the end of 2022 and has been on appeal since. That was a one-person company. The unresolved question in that case is precisely the one you inherit: whether YouTube's rolling cipher is a technological protection measure under §1201, and whether extracting audio circumvents it.
Why does the payment processor matter more than the copyright question?
Because it moves faster and there is no appeal. A takedown notice starts a conversation; an account closure is an email, a rolling reserve, and 180 days without your balance. If you have subscribers, you owe refunds out of money you cannot reach, and the site being offline does not stop the mandates. If you build this at all, build the free version.
What's the single most dangerous line of the naive build?
The one that passes a user-supplied URL straight to the fetcher. That is server-side request forgery with a friendly form in front of it: someone will point it at your cloud provider's metadata endpoint and at services on your private network. Allowlist the scheme and host, resolve the name, reject private and link-local ranges, and re-check after every redirect.
- 17 U.S.C. §1201 — circumvention of copyright protection systems
- YouTube Terms of Service
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice