ComicTagger writes the metadata your comic reader expects into the archive

Metadata is the point, not the comic

ComicTagger is a multi-platform app for writing metadata to digital comics, written in Python and PyQt. That description sounds narrow, and the reason it matters is that a digital comic file is a container with no catalogue inside it.

A CBZ is a zip archive of images. Nothing in the file records the series, the issue number, the publisher, the writer, the cover date or the summary. Your reader sees filenames. A comic library of any size is therefore a pile of images with names like scan_001, and the metadata has to come from somewhere else.

ComicTagger's job is to write that metadata into the archive in a format a reader understands, and to fetch the information from a database rather than from your memory. The README lists fetching comic information from Comic Vine, and support for the ComicRack and ComicBookLover tagging formats, with native full support for CBZ digital comics.

The audience is a collector or a librarian with a large library, which is why the feature list includes batch processing in the GUI for tagging hundreds or more comics at a time, and a command line interface enabling custom scripting and batch operations on large collections.

It is a tagging tool rather than a reader. It writes a sidecar of facts into the file so that other software can show you the series name instead of the filename.

Matching an issue from the cover image

The feature that decides whether the tool is usable at scale is automatic issue matching using advanced image processing techniques.

The logic is straightforward once you see it. A comic file has a cover image. The cover image identifies the issue. So the tool can compare the cover against the candidate covers in the database, pick the match, and fill in the metadata for that issue, rather than asking a human to type a series name and an issue number for every file.

That is why the database integration matters as much as the writing. Comic Vine is the source of the metadata, and the image matching is the lookup key, so a run over a folder is a batch of lookups rather than a batch of typing. The metadata then lands in the archive in one of the two supported tagging formats, which is what makes the result visible in a reader.

The two formats are the compatibility layer. ComicRack and ComicBookLover are the two tagging conventions that readers in this space understand, and writing in the wrong one means the tags are invisible to the software you actually use. Supporting both means the same tool works with either reader, and the choice becomes a setting rather than a reason to pick a different program.

The failure mode worth naming is a mismatch: a cover that is ambiguous, a variant cover, or a scan with a border or logo over the original art will not match cleanly. The README does not describe a confidence threshold or a fallback, so the practical assumption is that a human still checks the results, which is why the GUI exposes the match for review before the tags are written.

CBZ is written, CBR is read until you install rar tools

The archive handling is where the constraints live, and the README is specific about it.

There is native full support for CBZ digital comics, which is the zip based format and therefore the one the tool can rewrite without help.

For CBR there is native read only support. Full support is enabled by installing additional rar tools, and the README links to the RARLAB download page for them. In other words, out of the box ComicTagger can read a CBR archive to get at its images, but writing metadata back into it needs an external program that can handle the RAR container.

There is also a 7Z option, which appears in the pip extras as 7Z and provides support for CB7 and 7Z files. The archives listed as optional dependencies in the README are ICU, CBR, GUI, 7Z and all, with ICU flagged as the one that should always be installed because it ensures comic pages are supported correctly, and the README notes that currently ICU only exists in the latest alpha release.

That last sentence is a warning worth reading twice. The extra that the documentation says you should always install is, at the time of writing, only present in an alpha build, so a pip install of the stable line may not behave the way the instructions describe. The prebuilt binaries in the releases page are the safer starting point for a user who just wants the application to work, and the pip route is the one to test carefully.

Four ways to install, from a zip file to a package manager

The installation section covers four routes, and they suit different situations.

The simplest is the binaries. Windows, Linux and macOS binaries are provided in the releases page, and the README says to unzip the archive in any folder and run it, with no additional installation steps required. For someone who wants to try the application without touching a Python environment, that is the whole story.

The pip route installs the package with its extras:

$ pip3 install comictagger[GUI]

The extras are named in braces, and you can ask for one or more, for example comictagger[CBR,GUI]. The GUI extra installs the graphical interface, which means the plain install is the command line tool on its own.

On Windows there are two package managers, each maintained by a named contributor. Chocolatey:

choco install comictagger

and WinGet:

winget install ComicTagger.ComicTagger

Finally the source route, which the README lists with a Python version requirement and a clone:

git clone https://github.com/comictagger/comictagger.git

pip3 install .[ICU]

or the GUI variant, pip3 install .[GUI,ICU]. Note that the source instructions ask for Python 3.9 while the pip section does not state a version, which is a small inconsistency to keep in mind if your default interpreter is newer.

Two ways to work: batch in the GUI, scripts in the CLI

The README presents two distinct workflows, and they are aimed at different jobs.

The GUI route is batch processing in the interface, described as tagging hundreds or more comics at a time. That is the interactive case: a person points the application at a folder, it matches the issues, and the person checks and accepts the results.

The command line interface is for custom scripting and batch operations on large collections. For a library that a script already knows the contents of, that is the right tool, because the tagging decisions become repeatable and can be run unattended.

The difference in approach is worth stating plainly. The GUI is built around human review of matches, and the CLI is built around deterministic repetition. A collection that needs a hundred files checked by a person and a collection that needs ten thousand files handled by a job are different problems, and the project has an answer for each.

The repository layout reflects a mature Python project rather than a single script. There is comictaggerlib for the library, comicapi for the API layer, comictalker for the command line tool, plus testing, tests, build-tools and scripts directories, a pyproject.toml, a release_notes.txt, a todo.txt, an AUTHORS file and a pre-commit configuration.

The build system is setuptools with setuptools_scm, which derives the version from the repository tags and writes it into comictaggerlib/ctversion.py, so the package version follows the tags rather than being typed in by hand. The tooling is black and isort with a line length of 120 and the black profile, and pylint with PyQt6 whitelisted as an extension package.

The alternative: write the tags yourself

The other way to tag a comic library is to do it by hand, and for a small collection that is not a foolish choice.

The manual route is: open the archive with a zip tool, add the metadata file yourself in the right format, and rename the images so the reader can sort them. With a text editor and a template, that is a couple of minutes per issue, and the tags are exactly as good as what you type. The difference is entirely in effort and in coverage.

ComicTagger replaces the typing with a lookup, and the writing with a tool that knows the tag format. The Comic Vine integration plus the cover image matching is the part that scales, because it turns a per-file human task into a batch operation, and the two supported tagging formats remove the guesswork about which convention the file needs.

The trade is that the tool has opinions and dependencies. It needs the database to be reachable, it needs the archive to be a format it can write, and for a CBR collection it needs external rar tools. A hand-written tag has none of those requirements.

So the decision is about the size of the job and the shape of the collection. A dozen files, hand editing is faster. A few thousand files, or any collection where the metadata has to be consistent, the batch approach earns its keep, and the CLI is what makes it repeatable.

Version state and what to check before you commit

The release history is a string of betas, and the default branch is develop.

Version 1.6.0-beta.8 was published on 2025-10-05, 1.6.0-beta.9 on 2025-12-01 and 1.6.0-beta.10 on 2025-12-07, each named after a cover image in the way the project does for its tagged releases. The last push to the default branch was on 2026-10-19, and the repository is not archived.

So the code moves and the tagged releases are betas of a single 1.6.0 line. For a user, the releases page binaries are the reliable artefact, and the README's detail that the ICU extra currently exists only in the latest alpha release is a reminder to check what you actually get.

The licence is Apache-2.0, and the project is distributed on PyPI as comictagger, with the Chocolatey and WinGet packages alongside the binaries.

Two final checks are worth making before you point the tool at a library. The first is format coverage: confirm that the extras you need are present in the build you are installing, particularly ICU and CBR, since a missing extra shows up as pages that do not render or archives that cannot be written. The second is the source of truth: Comic Vine is the metadata source, so a run that produces wrong tags usually means a wrong match rather than a broken writer, and the GUI is where you catch that before it is written into the files.

Editorial conclusion

Adopt ComicTagger if you maintain a digital comic library and want the tags to match what Comic Vine and your reader expect, and if you are willing to install the extras your collection format needs. Do not adopt it for editing the comics themselves, since it writes metadata only, and do not expect CBR archives to be rewritten unless you add the rar tools, because CBR support is read-only by default. Before you script it, decide whether the CLI or the GUI suits the job, since the README presents batch tagging in the GUI and scripting in the CLI as two different ways of working, and check the current beta release notes because the latest tagged versions are 1.6.0 betas while the default branch is develop.

Frequently asked questions

Official sources

1. comictagger/comictagger on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases