Torrent File Editor: a Qt GUI for building and editing .torrent files

What the tool is for

Torrent File Editor is a Qt based GUI tool designed to create and edit.torrent files. That is the entire scope, and the repository is the application itself rather than a library or a plugin.

The toolset behind it is the reason the project can sit on three operating systems and three Qt generations. The sources are plain C++ with a Qt user interface, and the.ui files are in the tree, `mainwindow.ui` and `aboutdlg.ui`, which is the designer-form approach rather than hand-built widgets. Alongside that there is a set of small custom widgets with their own headers and implementations, `datewidget`, `lineeditwidget` and `combobox`, and a `nvwa/` directory.

The domain model is visible in the file names too. There is `bencode.cpp` with its delegate and model, `bencode.h`, `bencodedelegate.cpp` and `bencodemodel.cpp`, which is the BitTorrent encoding side, and a separate `json-builder.c`, `json-parser.c` and `jsonconverter.cpp`, which is the JSON side for the extension metadata and the tracker announce format.

There is also a `checkupdate.cpp` and an `appcast.json.in` file, which is the Sparkle update feed, and `dsa_pub.pem`, a public key used to verify that feed. The macOS build therefore has a signed update path built in.

The project is by Ivan Romanov, the licence is the GNU General Public License version 3.0 or later, and the default branch is master. The last push was on 2026-08-24, and the recent releases are v1.0.3 from 2026-06-05, v1.0.2 from 2026-03-23 and v1.0.1 from 2026-03-12.

One source tree, three Qt versions

The build instructions are the most substantial part of the README, and the headline is that the same source builds against Qt 4, Qt 5 or Qt 6.

The requirements are CMake 3.5 or newer, one of the three Qt versions, and Sparkle only for macOS. The Qt version is chosen with a `QT*_BUILD=ON` CMake cache entry, or with `QT_QMAKE_EXECUTABLE=/path/to/qmake`, which was added for autodetection in Qt Creator because Qt Creator adds that entry for each project. The README is explicit that if none of the above is used, Qt 5 will be used.

So the three builds are the same three commands with a different flag:

mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release -DQT6_BUILD=ON ..
make

The Qt 4 variant uses `-DQT4_BUILD=ON` and the Qt 5 variant uses `-DQT5_BUILD=ON`.

That is a real compatibility achievement rather than a trivial one, because Qt 4 dates from 2005 and Qt 6 from 2020, and the API differences between them are not small. The consequence for a user is that they can build the tool against whatever Qt their distribution or their company standardises on, which for a Linux distribution package is often a hard constraint.

There is a per-platform snag on Linux too. Building the Qt 5 version on Ubuntu 18.04 or later needs the Qt5 Linguist tools, which come from the `qttools5-dev` package, because the translation files have to be compiled. And if CMake reports missing Qt 6 requirements on Ubuntu, the README gives the packages:

The Linux, macOS and Windows build recipes

The three platform sections differ more than you would expect, and the differences are informative.

On Linux, the project should work for any distribution which has CMake and Qt. The Qt 6 case adds the missing-requirements step:

sudo apt install qt6-tools-dev libqt6core5compat6-dev

On macOS, only the Qt 5 version is supported. The build is the same shape, with an extra target for the disk image package:

mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make
make dmg # to build dmg package

The author states the environment he develops on: macOS Mojave 10.14.4 with Qt 5.5.1 and Sparkle 1.20.0. That is a 2019 environment, and it is a useful piece of information, because it tells you the code is not being compiled against a current Qt and that the Qt 6 path is the one most likely to need work.

On Windows the README is more guarded. The Windows version can be built with official MinGW Qt and Qt Creator, and to build the Qt 6 version you need to install the Qt5Compat module. Building with MSVC Studio is not tested and may not work. The author uses Fedora 31 with MinGW to build the Windows versions, and additionally builds portable static versions, packaging `mingw-qt4` modified with some patches to fix the build, with the details in `build.sh`. The build scripts in the repository root, `build.sh`, `build-mxe-shared.sh` and `build-mxe-static.sh`, are where that work lives.

The MXE scripts are for the cross-compilation environment, and having shared and static variants as separate scripts is what makes the portable static Windows build possible.

Translations, and how the project asks for help

The section on helping out is short, and it is mostly about translation.

The project is translated from English into several languages, and the README asks people to add new translations through Crowdin, noting that it is not difficult and requires no special knowledge. There is also an invitation to correct the author's English, with the acknowledgement that it is not good, and an email address.

Issues and pull requests are also invited, and the Crowdin badge at the top of the README points at the project there.

The translation list in the README is long. It runs from Afrikaans, Arabic, Bengali and both forms of Chinese, through Czech, Dutch, English, Finnish, French, German, Hebrew, Hungarian, Indonesian, Italian, Japanese, Korean, Polish, Brazilian Portuguese, Romanian, Russian, Spanish, Turkish, Vietnamese and Ukrainian. That is a genuinely international user base for a niche desktop utility, and it is the clearest signal in the repository about who uses this tool.

The Crowdin arrangement is the mechanism that makes it sustainable. A project of this size with one maintainer cannot hand-manage two dozen translation files, and a hosted translation platform lets contributors do it without a compiler or a build.

The licensing has a wrinkle that is worth flagging for anyone who wants to reuse the code. The README says the project is under the GNU General Public License version 3.0 or later, and the repository has a `LICENSES/` directory for the per-file licence identifiers, but the README's own SPDX header says `SPDX-License-Identifier: CC0-1.0` with no copyright holder, which is a public domain dedication for that file. Mixed licensing inside a GPL project is possible and legal, but it means the `LICENSES/` directory is the file to read rather than the README's one line.

The packaging and desktop integration files

The repository root contains the files a Linux desktop distribution needs, and they are a good way to see what the project considers a complete install.

There is `io.github.torrent_file_editor.Torrent-file-editor.desktop` and a matching `io.github.torrent_file_editor.Torrent-file-editor.metainfo.xml`, which is the AppStream metadata. The reverse-DNS identifier prefix in both is the modern desktop entry convention.

For the macOS bundle there is `MacOSXBundleInfo.plist.in`, a template rather than a finished file, which is the usual CMake approach so that the version and the bundle identifier can be filled in at build time. There is `app.rc.in` for the Windows resource script, `config.h.in` for the generated configuration header, `appcast.json.in` for the Sparkle update feed, and `CMakeDMGSetup.scpt`, an AppleScript that drives Disk Utility to lay out the disk image.

The `icons/` directory holds the artwork, and the `cmake/` directory holds the build modules.

Two more files are worth a mention. `dsa_pub.pem` is a public key for the update feed's signature, and `checkupdate.cpp` is the code that uses it, so the application can verify that an update it is told to download came from the project. For a tool that is a common target for tampering, because a modified binary that produces a malicious torrent file is a good attack, that is a sensible piece of the design.

Where Torrent File Editor is the wrong choice

The first wrong case is a server that needs to create torrents programmatically. This is a desktop GUI application, with a main window, dialogs and a tree view. There is no documented command line interface, no library API and no service mode, so anything that has to generate a torrent from a script is looking at the wrong tool.

The second is a user who needs the newer BitTorrent formats. The README describes creating and editing .torrent files and never mentions v2 or hybrid torrents, and the file layout shows a bencode implementation and a JSON implementation, which are the two halves of the v1 format and of the extension metadata. Whether the tool writes a v2 torrent is not something the documentation answers, and it is the first thing to check if that is your use case.

The third is a user who wants a lightweight utility. The build matrix spans three Qt generations and three operating systems, which is great for a distribution package and irrelevant for someone who just wants to edit one file. A torrent library in a language you already have is often the faster route.

The fourth is a team that needs an actively maintained tool on a current macOS. The author's build environment is Mojave with Qt 5.5.1, and the Sparkle update path depends on an appcast feed the project serves, which is a single point of failure for a tool whose whole job is to produce files other people will trust.

The fifth is a Windows developer who wants to build with MSVC. The README says plainly that building with MSVC Studio is not tested and may not work, and the supported route is MinGW with Fedora.

What the tool does well is the narrow thing: a desktop application for people who need to look inside a .torrent file, set a private flag, change a tracker, or reorder pieces, and want a window for it.

Editorial conclusion

Torrent File Editor suits a user who needs to create or edit a .torrent file by hand, particularly one with a private flag, a custom tracker or an unusual piece order, and who would rather use a desktop tool than a command line utility. It does not suit a server that has to create torrents programmatically, since this is a GUI application with no documented library interface, and it does not suit a user who needs the newer BitTorrent v2 and hybrid torrent formats handled, which the README does not mention. Before building it, pick your Qt version and set the matching `QT*_BUILD` cache entry, because the README is explicit that Qt 5 is used only when none of the three is specified, and read the Windows notes, since the author states that building with MSVC is not tested and may not work.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. torrent-file-editor/torrent-file-editor on GitHub