ArrowDL ships its own HTML parser so downloads do not depend on a browser

A standalone download manager with its own engine

ArrowDL, short for Arrow Downloader, is a standalone download manager for Windows, macOS and Linux. It is written in C++ and built on the Qt framework, and its distinguishing decision is stated in the README under the heading about how it works: it is a standalone application that embeds its own web engine, aiming to be free and independent and not to rely on any third party web browser technology.

That decision shapes what the tool is good at. Given a URL, ArrowDL downloads the page, parses the HTML and collects the links, then works through what it found. The screenshots in the README show that split into four categories of work: video streams, webpage content, a batch of files, and an overview screen, and the topic tags on the repository list the same range, with batch download, magnet links, torrent downloading, picture download and streaming among them.

The second path is the browser extension. The README says ArrowDL aims to work with the latest versions of Mozilla Firefox, powered by WebExtensions, and with other browsers including Chrome, Edge and Safari, and the repository carries a web-extension directory, with the project listed in the Chrome Web Store and as a Mozilla add-on.

So there are two ways in. The standalone application, which brings its own parser and does not care what your browser can do, and the extension, which runs inside the browser and uses the browser's own engine and permissions. The NativeClient.md file in the repository points at a third option, an alternative to ArrowDL itself.

The project site is arrow-dl.com, the default branch is develop, and the licence is the GNU Lesser General Public License.

Gumbo in the GNU builds, Chromium in the MSVC build

The internal web engine is the part of ArrowDL that is unusual, and the README documents it precisely.

For the MinGW and GNU versions, the parser is Google Gumbo Parser, described as a small pure C HTML5 parser that does not parse JavaScript.

For the MSVC version, the engine is Chromium, described as a full web engine that parses HTML and JavaScript.

That split is a compatibility decision with real consequences. The MinGW and GNU builds can parse the structure of a page, follow the links in it and pick out media references, but they will not run the JavaScript on the page, so a site that assembles its content at runtime will look empty to those builds. The MSVC build has a real browser engine and sees what a user would see, and it also inherits a very different dependency footprint.

The README anticipates that this will change. Because of the rapid evolution of web technology, ArrowDL is designed to implement new parsers or add existing ones if required, so the parser is treated as a replaceable component rather than a fixed choice.

For a developer, the practical consequence is that the two build families are not just different compilers of the same program. They are different programs with different capabilities, and a site that works in one may not work in the other.

Installing: the download page, Chocolatey and the extensions

Installation for end users is a download, and the README points at the project's download page for the build that matches your operating system. Usage is documented separately, on a tutorial page on the same site.

On Windows there is a package manager route, through the Chocolatey package:

choco install arrowdl

The README describes that package as a way to handle installation and updates, which is the usual argument for a package manager on that platform.

The browser integrations are the other installation channel. The badges at the top of the README point at a Chrome Web Store listing and a Mozilla add-on for Firefox, and the repository holds the web-extension directory that is the source for both.

There is a warning worth reading before installing. The License and Disclaimer section says to use the software at your own risk, that no author or contributor can be responsible for your use of the application, and it notes that the site can contain copyrighted work whose use has not always been specifically authorised by the copyright owner. That last sentence is about what the tool downloads rather than about the code, and it is the sort of line that belongs in a download manager's documentation, where the tool is by design pointed at other people's content.

The NativeClient.md document is described as an alternative to ArrowDL, for the case where the standalone application is not what you want.

Building from source with Qt Creator and CMake

The build instructions assume Qt Creator on Windows and a specific configuration, and they are worth reading because they name the dependencies rather than hiding them.

The configured kit in Qt Creator is assumed to be the auto-detected Desktop Qt 6.3.1 MinGW 64-bit, and libtorrent is assumed to be already compiled.

You open the project by selecting ./CMakeLists.txt, then go to the Debug page and click Configure. On the Projects page, under Build and Parameters, you set Boost_ROOT to the path to Boost and LibtorrentRasterbar_ROOT to the path to libtorrent. If the OpenSSL path is not recognised, you set OpenSSL_ROOT_DIR explicitly to the Tools/OpenSSL/Win_x64 directory inside your Qt 6 installation, and you are told to choose a different CMAKE_INSTALL_PREFIX.

Then you run CMake, build from the Editor page, and, to install, go back to the Projects page, select Build and Parameters, and in the Build step check install among the targets so that CMake builds and installs.

So the dependency list for a build is Qt 6, CMake, Boost, libtorrent and OpenSSL, and the tree is CMake-driven rather than qmake-driven, with a cmake directory at the top level of the repository. Other builds, including the ones that are not Windows specific, are covered in CONTRIBUTING.md.

The repository also carries the pieces around the code: 3rd for third party sources, include and src for the implementation, an installer directory, a test directory, doxygenMain.cpp with a doxyfile for the API documentation, and a version file.

Both the master and develop branches have GitHub Actions workflows for deployment, which is how the Windows, macOS and Linux builds and the browser extensions are produced.

What the README does not tell you

This is a short README for a project with a large surface, and the gaps are informative rather than accidental.

There is no feature list. The Overview is four sentences, and everything a user would want to know, what the downloader supports, which sites it handles, how the queue works, whether it can pause and resume, is not in the repository. The README sends you to the tutorial page on the project website instead, which is where the usage documentation lives.

There is no list of supported sources either, even though the topic tags mention youtube-dl, libtorrent, magnet links and streaming, and the screenshots show video, webpage content and batch downloads. Whether a given site works is therefore something you find out by trying it, or by reading the issue tracker.

The release state is the other thing to know. The tags are v4.2.0 from 2025-02-26, v4.2.1 from 2025-03-23, and v4.x.x from 2026-05-04, whose release name is ArrowDL v4.x.x DRAFT. A draft tag is not a stable build, and the last push to the default branch was on 2026-05-04, so the develop branch is where current work sits. The development branch is the default branch for that reason.

The troubleshooting and translator documents in the repository are signs of an active community around the project rather than a one-person tool, and TRANSLATORS.md points at the translation workflow, which is how a desktop application with a graphical interface gets localised at all.

The standalone app or the extension

The real design choice a user makes is between the two paths the project supports, and the difference in approach is larger than it first appears.

The standalone application embeds its own web engine. It parses the page itself, with Gumbo or Chromium depending on the build, and it does not need a browser installed, running or permitted to do anything. That independence is the point of the project, and it is also what makes the two parser families a real trade-off rather than an implementation detail. In exchange, you get a program that has to keep up with the web on its own terms, which is why the README says new parsers are designed to be added as the web evolves.

The extension path inverts that. It runs inside Firefox through WebExtensions, or in Chrome, Edge and Safari, and it uses the browser's engine, the browser's cookies and the browser's permission model. It is closer to the browser's own download handling, and it can do the things a browser can do, but it is limited to what the extension APIs allow and it shares the browser's process.

For someone who just wants the album behind a link, the extension is the smaller step. For someone who wants a queue, a batch, a separate window and a tool that does not care what their browser does next, the standalone application is the point. The NativeClient option described in the repository sits beside both, and is worth reading before you install, since the README presents it as an alternative to ArrowDL rather than a feature of it.

Editorial conclusion

Adopt ArrowDL when you want a download manager that keeps working when a browser changes, when you need to pull whole albums, batches of files or page resources rather than a single link, and when you are prepared to live with a small application rather than a scripting tool. Do not adopt it expecting a current release, since the most recent tag is a draft and the last push was on 2026-05-04, and do not expect the README to document the features, because the tutorial is on the project website. Before you install, read the download page and the TROUBLESHOOTING.md file, and check the LGPL-3.0 terms if you intend to redistribute the application or build on its sources.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. README
4. Releases
5. setvisible/ArrowDL on GitHub