Domain lists don't scale
The usual approach: maintain a hardcoded list of supported sites. A new file host appears, someone reverse-engineers its page structure, writes an extractor, adds the domain to a list, ships an update. Until that update reaches users, the site doesn't work.
50 sites means 50 extractors. 500 means 500. Every one of them breaks the moment a site redesigns a page or swaps its CDN. We didn't want to play that game.
Most "different" sites run the same software
Building a video platform from scratch is expensive. Most operators license a turnkey CMS from a vendor, slap their own logo on it, and launch. The underlying code barely changes because customizing it means giving up vendor patches.
So dozens of sites that look completely different on the surface are running the same template underneath. Same JavaScript player, same asset paths, same HTML structure, same API endpoints. If you can fingerprint the template, you handle every site running it, including ones that haven't launched yet.
How the detection actually works
Every CMS template ships with strings that survive rebranding: asset paths that still reference the vendor's directory, player init functions with distinctive names, page-level config objects with a specific shape. We call these structural markers.
A framework plugin fetches the page and checks for a combination of these markers. When enough of them match, we know what CMS we're looking at and how to pull the download URL out of it. The domain doesn't matter.
One of our framework plugins detects a player init function, a shared asset path, and a config blob. All three have to match. That combination identifies a CMS family running on several domains. One plugin, all of them handled, and a new site on the same CMS works the first time someone pastes a link.
Different sites need different tricks
Some CMS platforms embed quality hints right in the download URL,
like video_720p.mp4 or /mp4_hq/.
Veloxar reads the URL first and trusts the number over whatever
the page's UI claims. We've seen sites label a 360p file as "HD"
because it was the highest quality available for that particular
upload. The URL doesn't lie.
Other platforms put everything in the static HTML: player scripts, template paths, config blobs. One HTTP request and we know what we're dealing with.
Then there are the modern SPAs that resolve the video URL entirely in JavaScript, sometimes after decrypting a token or signing a CDN URL client-side. For those, Veloxar renders the page in an off-screen browser and lets the site's own JS do the work. We just grab the result. The framework plugin knows what timeouts and filters to use for its CMS family, so it works reliably without us having to reverse-engineer the obfuscation.
What you actually notice
You paste a link. It downloads. You don't check a compatibility list first. If the site launched last week and it runs a CMS we already know, it just works. You never filed a feature request, we never shipped an update. The technology was already recognized.
When we fix a quality-ranking bug in one framework plugin, it fixes the same bug on every site in that family. We changed one function last week and it improved extraction on 93 sites simultaneously.
Where it stands today
Veloxar ships 8 framework plugins that handle the most common CMS platforms in the file hosting and video streaming space. Combined with 10 host-specific plugins and 15 generic crawlers, that's 900+ sites from hardcoded lists alone, plus every site on a known CMS that hasn't launched yet. The number grows on its own every time an operator spins up a new domain on a platform we already recognize.
We're not racing to add domains. We identify the technologies that power the majority of sites and write one good extractor per technology. The coverage follows from that.