What this tool will and will not do

The short version

You are responsible for having authorization to download the file you paste in. This tool cannot check that and does not try to: it does not know who you are, what you have bought, or what the publisher of that file allows. The confirmation checkbox is a statement you make, not a permission this tool grants.

Only download media you own or are authorized to download.

This tool does not bypass DRM, authentication, paywalls, or access controls. There is no DRM circumvention here, and no access-control or authentication bypass of any kind — no cookies or credentials are sent, no tokens or sessions are minted, and no signature or cipher is solved.

Everything below explains what those sentences mean in practice, and what was left out of the product to make them true.

What "authorised" usually means

You are on solid ground when the file is yours, when it was published for download, or when its licence permits it. Your own recordings and uploads. Files your employer or client has given you access to for your work. Media under a Creative Commons or similar licence that allows reuse. Public-domain material. Podcast episodes, which are published as direct downloads by design. Assets from a press kit or an open dataset.

You are not on solid ground when the file is behind a sign-in, a subscription or a purchase you have not made; when the publisher offers streaming but not downloading; when a platform’s terms prohibit it; or when you simply do not know. Copyright rules differ by country and this page is not legal advice. If you are unsure, ask the rights holder.

Capabilities this tool does not have

These are not missing features awaiting a future release. They are excluded on purpose and will stay excluded, because implementing any of them would change what the product is.

1. No DRM decryption, and no handling of encrypted or protected streams.
2. No signature, cipher or token solving of the kind used to derive playback URLs.
3. No platform extractors. There is no code here that knows about any specific video site.
4. No page scraping and no reading of a site’s internal application state.
5. No private or undocumented platform APIs, and no impersonation of another application’s identity.
6. No authentication bypass, guest tokens, or anonymous session minting.
7. No CAPTCHA or anti-bot evasion.
8. No User-Agent, Referer or other header spoofing, and no rotating identities.
9. No retry logic that changes identity after a refusal.
10. No weakening of TLS certificate verification.
11. No watermark removal.
12. No server-side proxy or relay of any kind.
13. No cookies or credentials sent to any host.

Why the list is this specific

Before this tool was written, the ToolAcre team audited an existing open-source video downloader to see what could be reused. The answer was nothing. Its six platform extractors each worked by defeating a platform’s intended access path, and its download endpoint would fetch any URL a visitor supplied and stream it back through the server, with no scheme check, no host check and no private-address blocking.

Removing the prohibited behaviour would have removed the entire product, so this one was written from scratch with a different purpose. The list above is that audit’s findings turned into a permanent boundary.

Why there is no server

A proxy would make more links work. It would also mean your file passing through a machine you do not control, and it would create an endpoint that fetches arbitrary URLs on request — which can be pointed at private addresses inside the hosting network to reach things that were never meant to be public. That class of bug is called server-side request forgery, and it is one of the most commonly exploited vulnerabilities there is.

Choosing not to have a server removes the entire category. It also means the honest answer to "where did my file go?" is "from the host you named, to your device, and nowhere else".

How the URL check protects you

Only https links are accepted, so the file cannot be read or altered in transit. Links containing a username or password are refused, both because credentials in a URL are unsafe and because that syntax is a common way to disguise which host is really being contacted.

Private and internal addresses are refused: loopback, the private ranges, link-local addresses including the one cloud providers use for instance metadata, and names ending in .local or .internal. Obfuscated forms are refused too, because 2130706433, 0x7f000001, 0177.0.0.1, 127.1 and ::ffff:127.0.0.1 are all the same address as 127.0.0.1.

If you are the rights holder

This tool cannot access anything a visitor could not already fetch with their browser. It holds no index, stores no media, and has no server component that could host or cache your content.

If your files are being fetched in a way you do not want, the same controls that govern any direct link apply: require authentication, use signed URLs with short expiry, or omit the cross-origin header. This tool respects all three, because it is only a browser doing an ordinary request.

Questions

Limitations

• This page is not legal advice. Copyright and contract rules vary by country and by platform.
• The rights confirmation is a statement by you, not verification by this tool.
• The tool cannot tell whether you are actually entitled to a file, and does not try to.
• No platform-specific support exists or will be added, for any platform.
• Media requiring authentication is unreachable, because no cookies or credentials are ever sent.
• Hosts that refuse cross-origin reads cannot be downloaded from here, and no workaround is offered.