aria2: a command-line downloader that speaks HTTP, BitTorrent and Metalink at once

The problem aria2 solves, and who actually needs it

Most download tools pick one protocol and stay there. A browser handles HTTP. A torrent client handles BitTorrent. A package manager handles its own mirrors. aria2 sits across all of them. The README states it supports HTTP(S), FTP, SFTP, BitTorrent and Metalink, and that it can download a file from multiple sources and protocols at the same time, while data pulled over HTTP(S)/FTP/SFTP is uploaded to the BitTorrent swarm. That last point is the unusual one: aria2 is not just a client that happens to speak several protocols, it actively bridges them.

The audience is narrow and specific. This is a command-line utility, and the README lists "Command-line interface" as its first feature. If you are downloading a large ISO from a mirror list, seeding the same file to a swarm while you fetch it, or building an automated pipeline that needs to resume and verify chunks, aria2 is aimed at you. If you want a window with a progress bar, the project itself does not ship one. The related searches around "aria2 gui" and "aria2 manager" exist because the official tool leaves that layer to third parties.

How segmented downloading, Metalink and the RPC daemon fit together

The core mechanism is segmented downloading. aria2 splits a file into pieces and fetches them in parallel. Metalink support sharpens this: the README says that using Metalink chunk checksums, aria2 validates chunks of data while downloading, the same way BitTorrent does. So a Metalink file gives aria2 a list of mirrors plus per-chunk hashes, and the tool can pull chunks from different mirrors and verify each one as it lands. That is a different data flow from a normal HTTP client, which trusts the transport and checks the whole file at the end, if at all.

BitTorrent support is not bolted on as a separate mode. The README lists Fast extension, DHT, PEX, MSE/PSE, multi-tracker and UDP tracker support, plus WEB-Seeding and Local Peer Discovery. The bridge described above means a torrent download can be accelerated by ordinary HTTP mirrors, and the bytes you fetch over HTTP can be served back to peers.

Control is exposed two ways. The README lists a JSON-RPC interface over HTTP and WebSocket, and an XML-RPC interface. Combined with the ability to run as a daemon process, this is what makes the many web UIs and mobile frontends possible. aria2 itself stays a headless engine; everything graphical is a client talking to that RPC surface. The README also notes a disk cache to reduce disk activity, which matters when you are writing many small chunks concurrently.

Installing aria2 and running a first download

The README does not give a package-manager install line. It points to the project page at https://aria2.github.io/ and the online manual, and it documents building from source. The source is fetched with git, and the README gives this exact command:

$ git clone https://github.com/aria2/aria2.git

That creates an aria2 directory in your current directory, with the source files stored there. Building requires a C++11 aware compiler; the README names g++ and clang and the -std=c++11 flag. Dependencies are conditional. HTTPS needs OSX, GnuTLS, OpenSSL, or Windows. SFTP needs libssh2. Metalink and XML-RPC need libxml2 or Expat. gzip and deflate in HTTP need zlib. Async DNS needs C-Ares. If none of the optional crypto libraries are present, the README says an internal implementation supporting only md5 and sha1 is used.

On macOS and Windows, OS-level TLS is preferred, and you can turn that off with --without-appletls or --without-wintls respectively. GnuTLS takes precedence over OpenSSL when both are installed; you can force OpenSSL with --without-gnutls --with-openssl. libxml2 takes precedence over Expat, and --without-libxml2 flips that. You can also drop protocol support at configure time with --disable-bittorrent and --disable-metalink.

Once installed, the binary you call is aria2c. The README does not print a worked download example, but it does document reading URIs from a text file or stdin, with an optional destination directory and output file name, and it documents a configuration file. What you should expect from a run is aria2c reporting the split into segments and a progress summary per connection rather than one flat bar.

To run it as a background service that other clients can drive, the README documents both a configuration file and daemon mode. The RPC interfaces are what open the JSON-RPC and XML-RPC surfaces, and the manual is the place to look for the exact flags, since the README text available here does not spell them out. The README does not document a default RPC secret or authentication scheme either; check the online manual before exposing the port beyond localhost.

Where aria2 gets awkward

The dependency matrix is the first real cost. There is no single "install this and go" story in the README. You choose a TLS and crypto combination, and the README enumerates the valid ones: OpenSSL alone, GnuTLS with libgcrypt, GnuTLS with libnettle, Apple TLS, or Windows TLS. Mixing them incorrectly is possible, and the precedence rules (GnuTLS over OpenSSL, libxml2 over Expat, libnettle over libgcrypt) mean a build can silently pick a library you did not intend unless you pass the right --without and --with flags.

Release cadence is a second issue. The README describes a schedule of MINOR updates on the 15th of every month, with feature and documentation freeze 10 days before, and PATCH releases in between for security issues. The actual release history is sparser: release-1.37.0 landed on 2023-11-15, release-1.36.0 on 2021-08-21, and release-1.35.0 on 2019-10-06. So the stated monthly cadence and the shipped releases do not match. Anyone planning around predictable version bumps should read the NEWS file rather than trust the schedule paragraph.

Finally, aria2 is the wrong tool when you need a graphical experience with no additional software. It is also the wrong tool if you want a formal support relationship; the README opens with a disclaimer that the program comes with no warranty and is used at your own risk, and the licence is GPL-2.0.

aria2 next to curl and wget

curl and wget are the obvious alternatives, and the difference is architectural rather than cosmetic. Both are single-protocol-per-invocation tools built around one HTTP or FTP transfer at a time. wget can resume and mirror recursively; curl is a library and a client that excels at scripting one request at a time.

aria2's segmented downloading is the dividing line. Where wget fetches a file as one stream, aria2 opens multiple connections to the same server, or to several mirrors listed in a Metalink file, and reassembles the pieces. That is why the README can claim it "tries to utilize your maximum download bandwidth" on a single file. curl and wget have no equivalent chunk-level scheduler.

The second difference is BitTorrent. Neither curl nor wget speaks it. aria2 does, and the README's claim that HTTP-fetched data is uploaded to the swarm means the two protocols share one download session. If your workflow is "fetch this file, and also seed it," that is a capability curl and wget simply do not have. If your workflow is "fetch this one small file in a shell script," curl is lighter and already on almost every system.

Licence, maintenance and what an upgrade costs

aria2 is GPL-2.0. If you link against libaria2, the examples directory contains examples/libaria2ex.cc and examples/libaria2wx.cc, and the GPL applies to the combined work. That matters for anyone embedding the library in a product. This is a description of the licence text, not legal advice; talk to a lawyer about your specific distribution model.

The repository is not archived, and the last push was on 2026-06-25. That is recent enough that the codebase is still receiving commits, but the gap between the stated monthly release schedule and the actual tagged releases means upgrade planning should be based on the tags and NEWS, not the schedule paragraph. The MAJOR version has stayed at 1, so there is no major-version migration to plan for; the risk is in the dependency and build flags, which can change the linked TLS or crypto backend between builds even when the version number barely moves. Pin your configure flags in your build scripts.

Editorial conclusion

Adopt aria2 if you are comfortable in a terminal, need segmented HTTP downloads or BitTorrent in the same tool, and want to drive it from a script or a JSON-RPC client. Do not adopt it if you want a graphical download manager out of the box, or if you need a formal support contract. Before committing, verify that your distribution packages a recent build, decide which TLS and crypto libraries you will link against, and confirm that the RPC setup matches how you intend to expose the daemon.

Frequently asked questions

Official sources

1. aria2/aria2 on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases