xl-converter wraps five native image encoders in one desktop window

The value is the encoder set, not the interface

XL Converter is described as an easy-to-use image converter for modern formats, and the README is clear that the recommended way of using it is through the official binary releases, adding that the building process is time-consuming. That tells you what the project is. A GUI that puts several serious encoders behind one window, so you do not have to remember whether a given format wants cjxl, avifenc, jpegtran or oxipng and their individual flags. The formats covered are JPEG XL and AVIF for maximum compression, plus WebP, JPEG and PNG. The compression claims come from the project itself, with a JPEGLI section citing a Google blog post for up to 35 percent better compression ratio, and the lossless JPEG transcoding section claiming a 16 to 22 percent file size reduction that is reversible. Those are the project's own numbers and are worth checking on your own images, because the gain depends entirely on what you are encoding. The application is available for Windows and Linux, and the homepage is at codepoems.eu/xl-converter with documentation at xl-docs.codepoems.eu.

Transcoding an existing JPEG is a different operation from encoding

The lossless JPEG transcoding feature deserves its own paragraph, because it is the one thing here that is not just a format conversion. Transcoding an existing JPEG with jpegtran rearranges the data so the same pixels take less space, and the README states that this process is reversible, which means the original file can be reconstructed. That distinction matters when you have images you cannot re-encode, product photography where the master must stay bit identical, or archives where a lossy re-save would be destructive. A regular JPEG to JPEG conversion through most tools is a decode and re-encode, and it loses data every time. The project also lists ExifTool in its feature summary, which is the metadata side of the same problem, and downscaling as a separate capability that works from a target resolution, a percentage, the shortest or longest side, or a megapixel budget. The four ways of expressing a target size are a small detail that saves a lot of guessing when a web pipeline needs a specific budget rather than a fixed number of pixels.

Parallel encoding is the throughput lever

The parallel encoding feature is described simply, run encoders in parallel for increased throughput, and it is the reason the tool is interesting for a person with a folder of several thousand images rather than a person with one screenshot. The architecture that makes it possible is visible in the repository layout. There is a core/ directory, a ui/ directory, and a main.py entry point, and the requirements file is small: pyside6 at 6.10.3 for the interface, send2trash at 1.8.3 so a deleted file goes to the trash rather than vanishing, requests, psutil, and dmgbuild on macOS. That is a Qt desktop application, not a command line tool, and the separation between core and ui is what lets the encoders be driven concurrently while the interface stays responsive. The dependency list also says something about the build story. None of the actual image encoders are in requirements.txt, because they are compiled binaries, not Python packages.

The encoders are compiled dependencies, and the Makefile maps them

The Makefile is where the real dependency list lives, and it is a good document to read before you plan a build. The tool list names libjxl, libavif, imagemagick, libjpeg-turbo and oxipng, and for each platform the file records the binaries it expects and where they should be placed, so on Linux the libjxl entry lists cjxl, djxl, jxlinfo and cjpegli, the libavif entry lists avifenc and avifdec, the libjpeg-turbo entry lists jpegtran, and the oxipng entry lists oxipng. On Windows the binaries are expected to arrive as DLLs in the same directories, and the Makefile detects the host OS, refusing to run outside a MINGW64 shell on Windows and setting the platform to linux, macos or win accordingly. There is also a LICENSE_3RD_PARTY.txt at the top of the repository, which is what you would expect from a project that redistributes libjxl, libavif, ImageMagick and libjpeg-turbo inside its own binary.

Building on Linux needs a system full of build tools

The Linux instructions assume a Docker setup to run without root, pyenv, and a long apt line. The base packages are git, make, curl, fuse and p7zip-full, and then the xcb QPA dependencies for the Qt interface are installed, which is the usual set of X11 development libraries any Qt application needs on Linux. Python build dependencies follow, then Python 3.13 is installed and set globally through pyenv. The repository is cloned on the stable branch with a shallow clone, the native dependencies are compiled with a single make deps target, and the virtual environment is created with python -m venv env_build before the requirements file is installed.

git clone -b stable --depth 1 https://github.com/JacobDev1/xl-converter.git
cd xl-converter

make deps

python -m venv env_build
source env_build/bin/activate
pip install -r requirements.txt

Running it is then python main.py, and packaging for distribution is a PyInstaller script under misc/build_scripts, followed by python build.py. The same structure exists on Windows, where the README recommends MSYS2 with the MINGW64 shell, a long list of mingw-w64 packages including libjxl, aom, imagemagick and rust, and then a CMD step that creates the venv and runs main.py. The README warns twice that MSYS2 must be restarted after installing or upgrading packages, otherwise the build starts failing for reasons that look random.

Testing is split into unit and functional suites

The test setup mirrors the build setup, with a separate env_dev environment and a second requirements file for test-only packages.

python -m venv env_dev
source env_dev/bin/activate
pip install -r requirements.txt -r requirements_test.txt

The unit tests are run through a test.py entry point, and the documentation notes that you can control which tests run and that python test.py --help explains the options. A separate suite, test_convert.py, focuses on validating the program's output, and the two platforms run it differently. On Linux the functional tests need a virtual display, so xvfb is installed and the suite is launched with make test-convert. On Windows the same file is run directly with python test_convert.py. The functional tests being separate from the unit tests is a sign of how the project is structured, since the unit tests can run without the compiled encoders present, while the conversion tests need the whole stack built. A repository with a tests/ directory in addition to the two top level test scripts is also present, and the contributing guide lives under .github/CONTRIBUTING.md.

Where a different tool fits better

There are two clear cases for using something else. If you are converting images on a server, in CI, or inside a build pipeline, this is the wrong shape, because it is a graphical application with a PyInstaller packaging step rather than a library or a command line filter. The underlying encoders are all usable from a script, and if you want AVIF or JPEG XL in a pipeline, calling cjxl or avifenc directly, or using a Python binding to libjxl, gives you the same compression with none of the interface. If you are on macOS, the README lists availability for Windows and Linux, and the requirements file carries a dmgbuild entry for darwin, so a macOS artefact exists somewhere, but the documentation does not describe macOS as a supported platform and the build instructions cover only Windows 10 and Ubuntu. The second case is when you need editing rather than conversion. This tool converts, resizes and transcodes. It does not crop by rule of thirds, it does not remove a background, and it does not do colour correction. For those, an image editor is the right shape, and the value here is that you can feed the result of an edit straight into a better codec.

Editorial conclusion

xl-converter suits someone who works with large image libraries and wants JPEG XL or AVIF output, or wants to shrink existing JPEGs without a lossy re-encode, from a single window rather than a command line per format. It does not suit macOS users, since the README lists Windows and Linux, and it does not suit a server-side batch pipeline, because this is a graphical application with a PyInstaller build. Before adopting it, download the official binary rather than building it, and decide whether the format set covers your targets, since the tool is opinionated about which encoders it carries.

Frequently asked questions

Official sources

1. Issues
2. JacobDev1/xl-converter on GitHub
3. Project website
4. README
5. Releases