115Exporter hands 115 download links to aria2 over JSON-RPC

The link goes to aria2, not to the browser's own downloader

115Exporter is described in its own package manifest as an 'Assistant for 115 to export download links to aria2-rpc.' That phrasing sets the scope tightly. It is not a download manager and it does not replace a browser download. Its job sits between two things: a page you are looking at, and an aria2 process listening on a JSON-RPC endpoint.

The repository layout matches that job. The top level holds manifest.json, background.js, src/, _locales/, release/ and a gulpfile.mjs, which is the shape of a browser extension rather than a server or a command line tool. background.js is also the value of 'main' in package.json, so the background script is the entry point of the package. The effect is that the extension runs inside a browser where you are already signed in, captures a link from that session, and hands the link to an aria2 instance that you operate separately.

The practical consequence is a split responsibility. Where the transfer actually runs, its concurrency, its remote control and its queue all belong to aria2. The extension is the capture and dispatch step. If you have no aria2 process reachable over JSON-RPC, the extension has nothing to talk to.

Sign-in is delegated to fake115, and only on Chrome

The first thing the documentation addresses is not the extension at all. It points at a separate project, fake115, with the note that fake115 can be used to sign in on Chrome, linking to https://github.com/kkHAIKE/fake115.

That single line tells you where the credentials live. 115Exporter is not described as owning the login flow, storing an account, or refreshing a session. Authentication is a prerequisite you arrange elsewhere, and the documented route to that prerequisite is Chrome specific. The extension then operates on whatever session the browser already has, which is why the next step of the setup is to be signed in before expecting an export to produce anything.

For Firefox users this creates a gap in the written instructions. The install section covers Firefox in detail, but the sign-in guidance names only Chrome. The README does not document a Firefox equivalent for the fake115 route, so anyone setting this up on Firefox should expect to resolve that part on their own rather than from the project page.

Loading the unpacked release in Chrome and Firefox

Installation is a manual browser operation, not a package manager step. For Chrome the instructions are to open Settings, go to Extensions, then either drag the 115.crx file onto the page and install it, or enable Developer mode, choose Load unpacked extension, and navigate to the release folder.

For Firefox the route is the debugging console. Open about:debugging, click 'Load Temporary Add-on', navigate to the release folder, select manifest.json and confirm. The word temporary matters: a temporary add-on in Firefox is removed when the browser restarts, so this path is a per-session loading method rather than a permanent installation.

If you prefer to build the extension from the source tree instead of loading a prebuilt folder, the build commands live in package.json. The dev script runs a development server and the build script produces the production bundle:

npm run dev

Both delegate to gulp, with the environment selected by cross-env and NODE_ENV:

"dev": "cross-env NODE_ENV=development gulp serve",
"build": "cross-env NODE_ENV=production gulp publish"

The dependency tree is pinned in pnpm-lock.yaml, and the toolchain is a Gulp pipeline using rollup through gulp-rollup-each, sass for the stylesheets, terser for minification, postcss with autoprefixer, and gulp-zip for packaging. Style and script linting are wired up as npm run lint:fix, which runs stylelint over src/**/*.scss and eslint over src and background.js.

aria2 authentication is split by aria2 version

The configuration section is where the real constraints live, and the sharpest one is that there is no single auth setting for all aria2 builds. The documentation gives two alternatives, each tied to a version line.

For aria2 1.18.4 or higher, the recommendation is to set the rpc secret and use a JSON-RPC path shaped like http://token:secret@hostname:port/jsonrpc:

--rpc-secret=<secret>

For aria2 1.15.2 or higher, the alternative is a username and password pair, with a path shaped like http://username:passwd@hostname:port/jsonrpc:

--rpc-user=<username> --rpc-passwd=<passwd>

The version windows overlap, so the two schemes are not cleanly separated by age. A reader has to know which flag their own aria2 build accepts before they can build a valid URL, and getting it wrong produces an endpoint that the extension will call and that the daemon will refuse. The endpoint host and port are entirely up to you, which also means the extension can point at an aria2 running on another machine, as long as that machine is reachable from the browser and the credentials in the URL match the ones you started aria2 with.

Per-file options travel inside the JSON-RPC URL fragment

Download options are attached to the endpoint rather than to a separate form, using the fragment part of the URL. The documented example is:

http://localhost:6800/jsonrpc#max-connection-per-server=5&split=10

The fragment after the hash holds aria2 option names and values, and it applies to the specific file being sent. That design lets one global endpoint carry different settings for different links without a per-file configuration dialog, and it keeps the option set in the same string the extension already has to send. A reader should note that the fragment is not transmitted to the server in an HTTP request, so this is a convention the extension and the reader share rather than a field the daemon receives directly.

The port 6800 in the example is the conventional aria2 RPC port, and the path segment is /jsonrpc. The documentation uses localhost, so a default setup expects aria2 on the same machine as the browser. The host portion is what you change when aria2 lives on a NAS or a home server, and then the secret or the credential pair from the previous section has to travel with it. Nothing in the write-up explains what happens when the RPC call fails, so a wrong port, a missing secret or an unreachable host all look like the same silence from the extension.

Config changes only take effect after you press save

One instruction sits above all of the configuration advice: click the save button when you change config. It is easy to skim past, but it describes the persistence model of the extension. The options are not applied live as you type them into the settings interface; there is an explicit commit step.

That is the kind of detail that separates a usable setup from a frustrating one. Editing the JSON-RPC path, swapping the secret for a username and password pair, or adding a fragment such as #max-connection-per-server=5&split=10 all require a deliberate save before the extension will use them. A first-time user who changes the endpoint and immediately clicks a download link is testing the old configuration and may conclude that the new one is broken.

The same note is a hint about what this project does not do. There is no documentation of a headless mode, no command line entry point, and no unattended configuration file in the repository layout. The extension is operated by a person, in a browser window, with a settings panel.

What the documentation leaves open

Several gaps are worth naming before anyone commits to this in a workflow. The README does not document how to install or start aria2 itself, so a reader arrives with an RPC endpoint already in mind or goes looking elsewhere. It does not document rollback to an earlier extension version, and there is no changelog beyond the release tags in the repository, where v1.0.2 dates to 2026-06-10 and the two earlier tags, v0.5.1 and v0.5.0, sit in 2022.

There is also no documented behaviour for repeated links, for links that no longer resolve, or for the case where aria2 is running but its queue is full. No retry, logging or error-reporting story is given, and no export history is described. If a link silently fails to arrive, the write-up offers no way to distinguish an expired link from a refused RPC call.

The alternative to this extension is a manual one. Copying a link into an aria2 instance yourself removes the capture step and the sign-in dependency entirely, at the cost of doing the work by hand. The extension earns its place only when the number of transfers justifies automating that copy, which is a decision about your own workflow rather than a claim about the code. The licensing is GPL-3.0 or later, so redistribution and modification come with the requirement to keep the same licence terms; for a personal browser extension this rarely matters, but it is a constraint if you plan to build a packaged version on top of it.

Editorial conclusion

115Exporter makes sense if you already keep an aria2 daemon running somewhere and want links from a 115 page to land in its queue without copying them by hand. It is the wrong tool if you have no aria2 instance to point at, if you want a headless server-side client instead of a browser extension, or if you expect it to handle sign-in for you. Before installing, confirm which auth flag your aria2 build accepts, because the two options are split by aria2 version, and confirm that the release folder in the repository matches the version of the extension you plan to install.

Frequently asked questions

Official sources

1. acgotaku/115 on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases