What a Downloader Can Actually Reach

Support in code is not access from a server

Two entirely different things get called support, and conflating them is the reason published lists are unreliable rather than merely optimistic.

Handling code exists. The library knows a platform's structure and could extract a video from it. This is what a supported-sites list actually reports.

The platform answers. A request arrives from a datacentre address and the platform decides whether to serve it. Nothing in any list reflects this, because it depends on where the tool runs and on policy that changes.

The two come apart constantly. In our own testing, four platforms handled correctly by the library refused the request outright — the extraction code never ran. From a list's perspective all four are supported; from a user's perspective none of them work.

What refusal looks like

Platforms that decline requests from servers do it in recognisable ways, and none of them mentions downloaders.

Every one of these happens before the platform considers which video you asked for. That is why the resulting message is generic: there is nothing specific to report, and inventing a detailed explanation would send people fixing the wrong thing.

It also means retrying does not help and a different tool usually will not either — unless it runs somewhere else, which is the actual variable.

Why datacentre addresses are treated differently

The distinction that decides most of this is not the tool but where it lives.

A home connection belongs to a person. A datacentre address belongs to a server, and servers make requests at machine speed — which is what scraping looks like, and what platforms build defences against. Any web-based downloader is on such an address by definition.

Platforms respond along a spectrum. Some serve the request and watch. Some throttle after a threshold, which is what YouTube's bot check is. Some refuse outright. The judgement is similar everywhere; only the response differs.

This is also why your experience and a tool's can genuinely differ with neither being wrong. A video that plays perfectly in your browser may be unreachable from a server, because the platform is judging the address rather than the content.

It follows that a tool running on your own machine faces a different set of rules entirely. A local application makes requests from your home connection, so it inherits your standing rather than a server's — which is why a desktop tool sometimes reaches a platform no website can, and why recommendations from other users are unreliable evidence about a web service.

That difference is worth weighing when a specific platform matters to you. If it is one of the refusing ones, no web-based tool will help regardless of which you try, and a local open-source application is the only category with a real chance — with the trade-offs that involves.

Checking any tool in ten seconds

1. Paste a link from the platform you care about. Not a list, not a review — one real link.
2. Read what comes back. A specific message about the video means the platform answered. A generic failure often means it did not.
3. Try a second platform. If one fails and another works, the problem is platform-specific rather than the tool being broken.
4. Ignore the supported-sites page entirely. It reflects a library's capabilities, not the service's access.

This takes less time than reading the list, and it is the only method that produces an answer about the tool in front of you rather than about a library. It also has to be repeated occasionally, because the answer has a shelf life measured in months rather than years.

The three questions that decide everything

Reduced to its essentials, whether a given video downloads comes down to three things in order, and only the third is about the tool.

Will the platform answer this server at all? If the address is refused by policy, nothing else matters. This is the question no supported-sites list addresses.

Is the content public? Private accounts, subscriber-only material, age gates and direct messages need an identity. A downloader arrives as nobody, and no amount of engineering changes that.

Can the tool assemble what it finds? Only here does the software matter — whether it joins separate streams, handles unusual formats, and reports honestly when it cannot.

Most published comparisons of downloaders address only the third question, which is the least likely to be the reason something failed. Reading a failure correctly means working down the list rather than starting at the bottom.

Why claims outlive reality

Even honest lists drift out of date, and the mechanism is worth understanding.

Access is policy, not capability. A platform that serves datacentre requests this year may harden next quarter, and one that refuses may relax. Nothing changes in the tool when this happens, so nothing prompts anyone to update the page.

There is also no incentive to shorten a list. Removing platforms looks like losing features, and nobody re-tests eighty entries periodically. So lists grow and never shrink.

The practical implication is to treat any such list as marketing rather than documentation — including ours, if we published one. What a page claims about a platform tells you when someone last felt optimistic, not what happens today.

The same drift affects reviews and comparison articles, usually worse. A page ranking ten downloaders was written on one day, tested — at best — on a handful of links, and then left to accumulate search traffic for years. Nothing in it updates when a platform changes its policy, and the ranking stays confident regardless.

Which is why the ten-second test above beats any amount of reading. It costs less time than one review, it is current by definition, and it answers the only question that matters: does this tool fetch the video you want, today, from where it runs.

What tends to work, and why

Patterns are more useful than a list, because they survive changes.

Platforms with genuinely public pages tend to work. If content is meant to be seen without an account, a logged-out request is an ordinary visitor.

Platforms built around apps tend not to. Where the web surface is secondary, it is defended harder and maintained less.

Anything requiring a session never works. Private accounts, subscriber content, age gates and direct messages all need an identity a downloader does not have — and cannot acquire honestly.

Short-form video is usually the easiest case: single finished files, no assembly, no quality ladder. Long-form is harder for reasons of size rather than access.

A fourth pattern is worth adding because it cuts across the others: platforms with a large advertising business tend to be more permissive than platforms with a large subscription business. Content that exists to be seen widely is defended less than content people pay for, and that shows up directly in which requests get served.

None of these patterns is a guarantee, and they are more durable than any list. A platform that fits three of them will probably work; one that fits none almost certainly will not, whatever a comparison page claims.