LinkSwift: a Tampermonkey userscript that extracts direct download links from nine Chinese cloud drives

The browser download problem LinkSwift targets

Chinese cloud drives are built around their own clients. When a file lives in Baidu Netdisk or Quark, the web interface is often the only thing a Linux or ChromeOS user has, and the browser's own download path is a poor fit for large files: no resume, no segmented transfer, no queue. The usual workaround is to copy the file's share link into a desktop download manager, except the web page never exposes a plain HTTP address to copy. It exposes a button that starts a proprietary transfer.

LinkSwift inserts itself at that point. It runs as a userscript inside the drive's own web page, reads the file metadata the page already has, and asks the provider's public API for a direct address. The result is a URL you can paste into IDM, aria2, Motrix or any other manager. The project lists nine services: Baidu Netdisk, Aliyun Drive, China Mobile Cloud, Tianyi Cloud, Xunlei Cloud, Guangya Netdisk, Quark, UC and 123pan. The README describes it as a modified fork of the 网盘直链下载助手 userscript by 油小猴, with additional features on top.

The audience is narrow and specific. It is for people who already use a userscript manager, who have at least one of those nine accounts, and who want the file on local disk rather than inside a vendor client. It is not a scraper for public share links, and it is not a service that stores or proxies anything.

How the userscript gets a direct link out of the page

The mechanism is entirely client-side. Tampermonkey loads the script into the drive's page, where it can see the DOM and the same session cookies the page uses. When you select a file and trigger the script's panel, it calls the provider's own web API endpoints with your existing credentials and receives the download metadata the provider would have handed to its official client. The script then formats that metadata into a link, or a set of links, and shows them for copying.

The README is explicit about where those addresses come from: they are obtained through the public API interfaces of each drive provider. That sentence matters because it defines the failure mode. When a provider changes an endpoint, rotates a signing scheme or tightens a header check, the script breaks for that drive until the author patches it. A userscript has no server component to update centrally, so the fix reaches you only when you reinstall or when your manager pulls a new version from the source you installed from.

The README also draws a line around what the project claims. It states that the project does not promise, advertise or implement any circumvention of a provider's rate limiting, and that fast speeds observed in practice come from the provider's API policy, your local network, or a temporary bandwidth adjustment on the provider's side. Any third-party promotion using phrases like 加速下载 or 限速破解 is described as not representing the project's position. Treat that as the project's own scope statement, not as a performance claim in either direction.

Installing LinkSwift from a userscript manager

There is no package to install and no build step for the user. The README's installation section points at three sources for the stable version, and one for the canary version on the dev branch. You need a userscript manager first; the README's own badges reference Tampermonkey, including a BETA build, and the supported browsers listed are Chrome 76 and later and Edge 88 and later, on Windows, Mac, Linux and Android.

With Tampermonkey active, open the raw script URL. The manager intercepts the .user.js response and shows its install screen. The GitHub source is the primary one:

https://github.com/hmjz100/LinkSwift/raw/main/（改）网盘直链下载助手.user.js

Paste that into the address bar of a browser with Tampermonkey enabled. Tampermonkey should open an installation tab showing the script name and a version number; confirm it. The alternate sources are OpenUserJS and ScriptCat, and the README notes that OpenUserJS updates late. There is also a canary URL on the dev branch for the newest fixes.

After installation, open one of the supported drive sites and sign in as usual. The script adds its own panel to the page; the README does not document the panel's exact layout, so the first real task is simply to select a file and look for the script's entry point in the interface. Once a link appears, copy it into your downloader. If you prefer to keep the script current, note the README's warning that installing from GreasyFork is discouraged in favour of one of the listed sources, because a stale copy may stop working.

For contributors rather than users, the repository has an ESLint setup. The package.json defines a check script:

npm run check

That runs `npx eslint . --fix` against the repository. There is no test suite: the test script is the npm default that exits with an error.

Where LinkSwift stops working

The dependency on undocumented provider APIs is the central limitation. Every supported drive is a separate integration, and each one can break independently when the provider changes something. The README's update log shows this pattern in miniature: version 1.1.4, dated 2026-09-09 and marked as a test build rather than final quality, adds support for one more drive. The stable release before it, v1.1.3, is dated 2026-02-18. A gap of that length between stable releases is normal for a one-maintainer userscript, but it means a broken drive may sit broken until the next release.

Support channels are deliberately narrow. The README states that bug reports should go to the GitHub issues page and that feedback on other platforms will not be handled. If you are not willing to file on GitHub, you are effectively without support.

There is also a class of file the approach cannot help with. If a drive serves a file only through a client-side encrypted or chunked protocol, or if the account lacks the entitlement the API checks for, no userscript can conjure a direct link. And because everything runs in your browser session, the script inherits your account's permissions and limits. It is the wrong tool if you want unattended, headless transfers on a server: there is no CLI, and the extraction depends on a logged-in browser page.

LinkSwift against PanDownload and a plain download manager

The closest comparison people search for is PanDownload, and the difference in architecture is the whole story. PanDownload was a standalone desktop application that logged into a cloud account and managed transfers itself. LinkSwift is a browser script that produces a link and hands it off. That means LinkSwift has no account storage of its own, no transfer engine, and no server infrastructure to be shut down; but it also means it cannot download anything by itself. You still need IDM, aria2, Motrix or similar to do the actual work, and the quality of the transfer is that tool's responsibility.

Against simply using your browser's built-in downloader, the difference is resume and queueing. A browser download of a multi-gigabyte file from a drive page is fragile. A download manager with segmented transfers and resume is not. LinkSwift exists to bridge those two worlds, and the README's topic list names aria2 and Motrix explicitly as intended companions.

Against the original 网盘直链下载助手, this is a fork. The README says it adds more features and lists a companion set of scripts for 123pan, Baidu and Aliyun that the author maintains separately. If you only need one drive and the upstream script still works for you, the fork's broader drive list is the main reason to switch.

Licence, maintenance and what an upgrade costs you

The repository is licensed AGPL-3.0, which is the strongest of the common copyleft licences and carries a network clause: if you modify the script and let others use it over a network, you are expected to offer them the source. For a userscript that most people install and never modify, the practical effect is limited, but anyone forking it into a hosted service should read the licence text rather than assume userscript distribution is exempt. Nothing here is legal advice; the LICENSE file in the repository is the authority.

The maintenance picture is mixed and worth stating plainly. The repository is not archived, and the last push was on 2026-09-10, which is recent. But the release cadence is slow: v1.1.3 landed on 2026-02-18, and the version after it, 1.1.4, is still labelled a test build in the README. The package.json version, 1.1.3.1, does not match the released 1.1.3 either, which suggests the metadata is not tightly maintained. The README itself notes, half-jokingly, that one person is doing the modification work.

Upgrading is cheap when it works: you reinstall from the same raw URL and Tampermonkey replaces the old copy. The cost is not the upgrade, it is the drift. If you installed from a mirror that updates late, you can be running a version that no longer matches the providers' current APIs and not know it. The README's own advice, to pick a source deliberately and overwrite-install from it, is the mitigation.

Editorial conclusion

LinkSwift suits users who already run Tampermonkey and want their cloud drive files in a local download manager instead of a browser tab. It is not for anyone expecting speed-limit removal: the README states the project does not break or advertise circumvention of provider throttling. Before adopting it, confirm your drive is in the supported list, install from the GitHub raw URL rather than a mirror, and check that the downloader you intend to use accepts the link format the script produces.

Frequently asked questions

Official sources

1. hmjz100/LinkSwift on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases