# Camtd: a Chrome extension that hands downloads to aria2

> Camtd is a browser extension that intercepts the downloads you start in Chrome and passes them to a local aria2 daemon over its JSON-RPC interface, with the AriaNg interface bundled in for the display. The idea is old and still sound, but the repository shows its age in the build toolchain, in the changelog and in the absence of a licence file.

**jae-jae/Camtd** — Chrome multi-threaded download manager extension,based on Aria2 and AriaNg.  Chrome多线程下载扩展。

- Repository: https://github.com/jae-jae/Camtd
- Website: https://1team.top
- Stars: 998 · Forks: 85
- Language: JavaScript
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/jae-jae-camtd

## The shape of the thing

Camtd is not a downloader in itself. It is the browser half of a download system whose real work is done by aria2, the command line downloader, and whose interface is AriaNg, the web front end for aria2. The extension watches for downloads that Chrome is asked to start, intercepts them, and forwards them to a running aria2 process through the JSON-RPC interface that aria2 exposes, and the progress and control then appear in the bundled AriaNg interface. The reason to build it this way is that aria2 splits a file into segments over several connections and stores partial downloads. So the extension is a bridge between a click in the browser and a downloader that was never designed for the browser, and the repository contains the extension code, the vendored interface and the build tooling for both.

## The aria2 side, and the security that comes with it

The usage section starts with the daemon, and the command it gives is the part to read carefully:

```bash
aria2c --enable-rpc --rpc-listen-all=true --rpc-allow-origin-all
```

The extension then talks to the resulting JSON-RPC path, in the form of a URL with the host and port. The two flags in that command are the risk. Listening on all interfaces means the RPC port is reachable from anywhere that can route to the machine, and allowing all origins means a page in any browser can talk to it, which together mean that an unauthenticated daemon on a network is an open download proxy. The README knows this and gives the mitigations, recommending a secret on recent versions of aria2, with the path taking the form of a URL carrying a token and a secret, and a username and password on older ones. The versions matter, because the secret option is only described from 1.18.4 onwards and the password option from 1.15.2 onwards, so a distribution still shipping an older aria2 leaves the weaker of the two options.

## What the extension does with the downloads it intercepts

The changelog records the behaviour most clearly, because it is short and specific. The 0.0.8 release added an intercept filter with a blacklist and a whitelist, so the extension can be told which downloads to take over and which to leave alone, and the same release removed a limit on the number of simultaneous connections the extension would allow. The 1.1 release taught it to ignore the blob protocol, and the 1.4 release extended that to ignore every protocol that is not http, https, ftp or sftp, which is the sensible default since those are the ones aria2 can actually fetch. The 1.0 release added a notice when the configuration is wrong, and the 1.2 release fixed the filter, tidied the sidebar and improved the status messages. So the interception rules are configurable, the protocol handling is conservative, and the tool tells you when it is not set up properly.

## Building the extension and the interface

The build instructions are split into two halves, because the interface is a separate project living in its own directory in the tree. For the extension, the sequence is to install the dependencies with yarn, transpile the source with a babel task, install the bower components, and then either watch for changes during development or build a production version of the extension. The interface is built the same way from inside its own directory, with its own dependency install, a bower install, a clean and build pair of tasks, and a serve task that starts a development server for the interface alone. The toolchain is the giveaway about the age of the project, since bower and a gulp task setup of that kind predate the current JavaScript tooling, and anybody picking this up today should expect to modernise the build before anything else.

## Where the project stands

The release history and the changelog tell two different stories, and the difference is informative. The changelog in the README ends in 2018, with the last entry being the 1.4 release, while the published releases carry dates from 2018 and 2019, with 1.4.2 from August 2019. The last push to the branch is more recent, on 2026-08-18, so somebody has been touching the repository without publishing anything. The practical conclusion for a reader is that the code predates the current Chrome extension platform, whose manifest requirements and background model have both changed since, and a reader who wants to use this today should assume a porting exercise rather than an install. There is also a licensing gap, because the README states that the project is under the MIT licence while the top level of the repository has no licence file at all, which is worth raising with the author before you redistribute any of it.

## Camtd next to aria2 on its own

The honest alternative is to skip the extension. aria2 with the AriaNg interface serves the same function, a web page that shows the downloads aria2 is running, and the download itself is unaffected by whether the request came from the browser or from a command line. What the extension adds is the interception, so that a click on a link in a page becomes a segmented download without you thinking about it, and the filter and the blacklist that let you decide which sites it takes over. What it costs is a component that has to keep working inside a browser that changes its extension model every few years, plus the requirement that a local daemon is running with an RPC interface that other things on your network could otherwise reach. For a person who downloads a handful of files by hand, the daemon alone is the simpler system, and for a person who pulls large files from a browser all day, the interception is the reason to keep the extension.

## Conclusion

Camtd fits a user on an older Chrome who wants multi-connection, resumable downloads for files that the built-in downloader struggles with, and it fits a developer who wants to read a small, readable extension that speaks a documented protocol to a local daemon. It does not fit a current Chrome installation without work, because the extension has not been rebuilt against the current extension platform, and it does not fit a security conscious user who will run an RPC interface listening on all interfaces without a secret. Before using it, decide whether you need the browser interception at all, because aria2 with its own web interface can do the same downloads, and read the licence question with the author, since the README states MIT but no licence file is present.

## FAQ

### What does the Camtd extension do?

It intercepts downloads started in Chrome and hands them to a local aria2 daemon over its JSON-RPC interface, so they are fetched with multiple connections and can be resumed, while the AriaNg interface bundled in the repository shows and controls them.

### How do I set up aria2 for Camtd?

Start aria2 with RPC enabled using aria2c --enable-rpc --rpc-listen-all=true --rpc-allow-origin-all, then point the extension at the JSON-RPC path. The README recommends a secret on aria2 1.18.4 or newer, or a username and password from 1.15.2 onwards.

### How do I build the Camtd extension?

Install the dependencies with yarn, transpile the source with the babel task, install the bower components, and then either use the watch task during development or the build task for a production version of the extension.

### How is the AriaNg interface built separately?

The interface lives in its own directory in the repository, where you install the dependencies with yarn, run the bower install, build with the clean and build tasks, and start the development server with the serve task.

### Which protocols does Camtd intercept?

Only http, https, ftp and sftp. The changelog records that the blob protocol and then all other protocols are ignored, and that an intercept filter with a blacklist and a whitelist was added so you can decide which downloads are taken over.

### Which licence does Camtd use?

The README states the MIT licence, but the repository does not contain a licence file at its top level, so the terms are worth confirming with the author.

## Sources

- [Issues](https://github.com/jae-jae/Camtd/issues)
- [jae-jae/Camtd on GitHub](https://github.com/jae-jae/Camtd)
- [Project website](https://1team.top)
- [README](https://github.com/jae-jae/Camtd/blob/master/README.md)
- [Releases](https://github.com/jae-jae/Camtd/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jae-jae-camtd