bittorrent-tracker-editor: adding and removing trackers across a folder of torrent files

What it does, and the warning the project puts above everything

bittorrent-tracker-editor adds or removes BitTorrent trackers from torrent files, and the feature list is a short inventory of one specific job done well in bulk.

You can select one torrent file or a folder of torrent files. You can add one or more trackers at the same time, and remove one or more trackers at the same time. You can remove all the trackers to create a trackerless torrent, described in the documentation as a DHT torrent, which is the state where the file relies on distributed hash table lookups and magnet links rather than on an announce server. You can show the content of a torrent file, and you can download a list of stable trackers from newTrackon or from ngosang rather than typing URLs in by hand.

The warning at the top of the documentation is the part a reviewer should read first: there is no backup function in this software, use it at your own risk, and bittorrent works fine without this program, you probably don't need this software.

That last sentence is unusual and it is not a throwaway. It is the author telling the reader to justify the tool to themselves before installing it, and it sets the expectation that this is a utility for a specific, occasionally awkward job rather than something you keep running.

The project also draws a line against the alternatives. For editing one torrent file, the documentation points at an online editor at torrenteditor.com. For editing multiple torrent files, use this program, because it is made for changing multiple torrent files. That is the whole scope claim, and it is a narrow one.

The private and public flag, and why it changes the info hash

One feature deserves its own attention because it has a consequence the documentation spells out plainly: you can change the public and private flag, and the warning attached to it says this will change the torrent info HASH.

That is the single most important technical fact about this tool, and it is easy to skim past as a footnote.

A torrent file contains an info dictionary, and the info hash is a digest of that dictionary. The announce list, the tracker URLs, is a separate part of the torrent file, sitting outside the info dictionary, which is why adding or removing a tracker does not change the infohash and does not change the torrent's identity. The private flag, however, lives inside the info dictionary, because it is part of what the client publishes about the swarm. Change it and the infohash changes, and with it the identity of the torrent.

Practically that means: a file whose flag you flip is a different torrent to every tracker, every client and every existing peer set. It will show zero seeds, it will not resume an existing download, and it will not be recognised as the same content. That is a feature when the goal is to take a torrent out of a private tracker and make it public, and it is a footgun if the goal was something else, which is presumably why the flag is a deliberate action with a checkbox rather than a side effect of adding a tracker.

The 1.33.0 release also added a separate tab page for the private torrent, together with a check box to skip the announce check in the URL and a command parameter for the same, and support for the Info Source tag used by private trackers, with a matching command parameter. Those two features exist because private trackers do not use a plain announce URL, and a tool that assumed the public form would have produced a file those trackers reject.

Presets, console mode and tracker order

The three options that make this practical for batch work are the preset files, the console mode and the tracker ordering controls.

The preset mechanism reads add_trackers.txt and remove_trackers.txt from the same folder as the executable when those files are present, and the documentation gives the equivalent location for the Linux snap version, which is home/snap/bittorrent-tracker-editor/common/. So the tool can be preconfigured for a specific library of torrents, with the tracker set you want added and the tracker set you want stripped, and then pointed at a directory. That is the difference between a tool you use once and a tool you can put in a script.

There is an optional start as console program mode, and the details are in a readme.txt in the enduser/ directory of the repository, alongside a tracker-order-modes.svg diagram that documents the ordering options. Two command parameters are named in the changelog: -SAC for skipping the announce check in the URL, and -SOURCE for the info source tag for private trackers. The presence of command line flags is what makes the console mode usable from a script rather than only by hand.

The two parameters named in the changelog are:

-SAC
-SOURCE

The first suppresses the announce check in the URL, and the second sets the info source tag that private trackers expect.

Tracker ordering is the other batch-relevant control, and the changelog shows it being added and refined over several releases. There is an option to add trackers while keeping the original unique trackers list intact, which is the safe default for anyone who does not want to lose working announce URLs, and an option to randomize tracker order for each torrent file, which matters because a fixed order makes a client try a dead tracker first every single time. The 1.32.0 release also added a warning when the torrent file is read only, and fixed handling of trackers over https, of torrent files whose string size is larger than 1 MB, and of WebTorrent entries that do not have an /announce path.

Getting it: three build channels for three platforms

The distribution story is unusually complete for a small desktop utility, and it is organised by operating system.

The main channel is GitHub Releases, which carry an executable file for Windows, macOS and Linux, and the project publishes a Snap build and a Flathub build alongside. The Snap is for Linux on amd64 and arm64 and comes from the Snap Store, and the Flathub build, with the application id io.github.gerryferdinandus.bittorrent-tracker-editor, is for the same two architectures. The build table in the documentation lists continuous integration on GitHub Actions with separate workflows for Ubuntu, Windows and macOS, producing a Linux amd64 binary, a Windows amd64 binary and a macOS universal binary.

The application itself is written in Pascal and built with the Lazarus IDE, and the topic list for the repository names Lazarus, Free Pascal and the three desktop platforms. The repository tree is organised around that: a source/ directory for the code, a submodule/ directory with a.gitmodules file, an enduser/ directory holding the readme.txt and the tracker-order-modes diagram that the console mode documentation points to, a snap/ directory, a metainfo/ directory for the store metadata, a test_torrent/ directory with test material, and a SourceCodeBuild.txt describing how to build from source.

The releases tell a slower story than the pushes. The recent tags are V1.33.1 from 2024-12-08, V1.33.0 from 2023-11-17 and 1.33.0.beta.6 from 2019-09-08, while the last push to the repository was on 2026-10-22. So work continues on the main branch and the packaged releases are less frequent, which matters for the V2 torrent fix specifically, because that fix is in the 1.33.1 tag rather than in whatever is on the branch.

What the changelog says about tracker formats, and where the tool stops

The release history is a good catalogue of the ways a torrent file can surprise you, and reading it explains the design of the tool better than the feature list does.

The 1.33.0 release, in November 2023, added OpenSSL 3 support and fixed dark theme handling on macOS. It added the direct download support for the ngosang tracker list through a menu, the private torrent tab page, the skip announce check option and its command parameter, and the Info Source tag support for private trackers with its command parameter. It fixed support for /announce.php paths, fixed an issue with uploading a tracker list to newTrackon, fixed the handling of WebTorrent entries that have no /announce path, made wrong tracker URL formats from torrent files unselected by default, added uploading trackers to newTrackon, and added verification of the working status of public trackers using newTrackon data.

That last item is the one that changes the character of the tool. Verifying whether a public tracker is actually working, and offering an upload path to newTrackon, means the program talks to the network and participates in a shared tracker health effort rather than being a purely local file editor.

The 1.33.1 release then fixed the single most basic failure mode: it could not open a torrent file in V2 format. V2 is the BitTorrent v2 format, a different torrent structure from the v1 format the tool was written against, and a program that rewrites the info dictionary has to understand that structure correctly to avoid producing a broken file.

The limits are equally clear. The tool is a desktop application for a person sitting at a machine, and the console mode exists for scripting but is documented in a plain text file rather than a proper command reference. There is no automatic backup, so a batch run over a folder is a run where one mistake damages every file it touches. And the private and public flag remains the operation with a consequence, which is that the program can produce a file that no longer matches any torrent you already had.

Editorial conclusion

bittorrent-tracker-editor is worth having on a machine where you have accumulated a folder of torrents with dead announce URLs, because it edits them in bulk rather than one at a time, because it can strip every tracker to leave a magnet-capable DHT torrent, and because it can pull a current list of working trackers from newTrackon or the ngosang list instead of making you paste URLs by hand. It is the wrong tool for a single file, where the project points you at an online editor, and it is the wrong tool if you need to undo a mistake. Before you run it over anything you care about, check three things: that the project states there is no backup function and that you use it at your own risk, so copy the files first; that changing the public and private flag changes the torrent info hash, which means the edited file is a different torrent to every tracker and every client that already has it; and that the last tagged release is V1.33.1 from 2024-12-08, which is the version that fixed opening V2 format torrent files, while the last push to the repository was on 2026-10-22.

Frequently asked questions

Official sources

1. GerryFerdinandus/bittorrent-tracker-editor on GitHub
2. Issues
3. License: MIT
4. README
5. Releases