sticker-convert moves animated stickers between WhatsApp, Telegram, Signal and the rest

One sticker file, twelve apps, no shared format

sticker-convert is described as a Python script for creating, downloading, converting and compressing and uploading stickers from multiple instant messaging applications. It runs with a GUI and a CLI on Windows, macOS and Linux.

The problem it solves is that each messaging app has its own sticker format and its own rules about size, transparency and animation. A sticker you saved in one app is not a file the next app will accept, and the animated formats differ too, which is where the complexity concentrates.

The list of supported applications is long: Signal, Telegram, WhatsApp, Line, Kakao, Naver Band, OGQ, Viber, Discord, iMessage, Mastodon and Misskey. The README notes that Line, Kakao, Naver Band, OGQ and Discord are download only, while iMessage support is about creating an Xcode sticker pack project for sideloading.

Both static and animated stickers are supported, with transparency support, which is the requirement that rules out many simpler tools. The dependencies confirm the approach: imagequant for lossy palette compression, apngasm_python and pyoxipng for APNG assembly and optimisation, rlottie_python for Lottie animation, resvg_py for SVG rendering, and PyMemoryEditor and psutil for the memory handling that the FAQ discusses.

The project is licensed under GPL-2.0, and the package on PyPI is sticker-convert.

The compatibility table is the real documentation

Rather than a feature matrix, the README leads with a table of what is actually possible per application, and the columns are download and upload.

Signal supports both, and the upload path needs a `uuid` and `password` if you want the program to upload the pack automatically, with a manual route through Signal Desktop as the alternative. Telegram supports download for both stickers and custom emoji but requires a bot token or a Telethon setup, and upload additionally needs a token and a user_id, or Telethon, or manual upload.

The download-only group is Line, Kakao, Naver Band and OGQ, each marked as needing submission for manual approval on upload, and Discord is download only and requires a `token`. Viber supports both, with upload requiring `viber_auth`. Mastodon supports both with a `token` for download and `mastodon_cookies` for upload. Misskey supports both with a `token` and a `misskey_token`.

WhatsApp is the odd one out on the download side: you can sign in to WhatsApp inside sticker-convert to help it download, or you find packs manually, extract them from your phone, or extract them from WhatsApp Web.

That table is the thing to read before anything else. Whether the tool is useful to you depends on which app you need to upload to, not on which app you download from.

Four ways to install it, including one that needs no install

The distribution options are unusually broad for a tool of this kind, and each suits a different situation.

There are pre-compiled releases for Windows, macOS and Linux as an AppImage. On Windows you unzip the download and run sticker-convert.exe, or take the msi installer instead. On macOS you unzip and open first_launch.command, and the README walks through the gatekeeper prompt that appears, where you click Done rather than Move to Trash, then allow the file in Security and Privacy. On Linux you either make the AppImage executable and run it, unzip the archive and run sticker-convert.bin, or install the AUR package with makepkg -si, and the README notes the binary is compiled with glibc 2.17, so it needs Debian 8 or newer, Ubuntu 13.10, Fedora 19 or CentOS and RHEL 7.

For people who want it in their own Python environment, there is a pip package, sticker-convert, launched with either the sticker-convert command or python -m sticker_convert. The project metadata says it needs Python 3.8 or newer and classifies itself for Python 3.8 through 3.14, and the console script is wired to sticker_convert.__main__:main.

There is a Docker image for running on Linux, and a Google Colab notebook that runs entirely on Google's servers and returns the result through Google Drive. The README is honest about the trade-off there, noting it may be slower than running on your own machine, at roughly 15 seconds per file unless converting to .apng, and about a minute per file when you do convert to .apng.

The Docker image mounts two directories and forces a DNS server

The compose file shows how the container is meant to be used, and it is short enough to read in full.

The service runs the laggykiller/sticker-convert image, with alternative tags for a minimal CLI build and a minimal GUI build, and the build section is present but commented out for local builds. The two directories that matter are mounted into the container:

    volumes:
      - ./stickers_input:/home/app/stickers_input
      - ./stickers_output:/home/app/stickers_output
    ports:
      - 5800:5800 # Port for Web UI

Port 5800 exposes the web interface, and the VNC port 5900 is available but commented out. A credentials file can be mounted into the container at the config path, also commented out, and /dev/shm is mapped in.

The DNS entry is the detail worth understanding:

    dns:
      - 1.1.1.1 # Or else download/upload to telegram fails in Docker

That comment is a real constraint rather than a preference. Whatever resolver the container inherits by default is not enough for Telegram's servers to be reached for a download or an upload, so the compose file pins 1.1.1.1.

The Docker image itself is a multi-stage build. The min-cli stage starts from debian:12, installs build tools and Python 3.13 through pyenv, installs the pinned requirements, copies the source and the locale update script, then purges the compilers so the runtime image carries no build toolchain. The GUI stage is based on jlesage/baseimage-gui with a virtual display, which is how the desktop interface runs headless inside a container.

Where the time goes, and why the FAQ admits it is slow

The FAQ has a section titled Conversion is slow and another titled Running out of RAM and system frozen, and those two entries describe the cost of the animated formats better than any feature list.

The reason is visible in the dependency list. Animated stickers are not one format. Telegram uses TGS, which is a gzipped Lottie animation, and rlottie_python handles that. WhatsApp uses its own animated sticker container, and the WhatsApp guide is a separate document. Converting between them means decoding one animation format, rasterising frames, and re-encoding into the target format, and where transparency is involved, each of those steps can be expensive.

The Colab note gives a figure, roughly 15 seconds per file when not converting to .apng and about a minute per file when you do, which is a useful baseline for judging whether a batch job is viable.

The memory entries point at the same issue. PyMemoryEditor and psutil in the requirements are there to observe what a conversion is doing to the machine, and the compose file mounts /dev/shm precisely so that the container has shared memory to work with. On a laptop with a modest amount of RAM, converting a large animated sticker set is the operation that will make the system unresponsive, and the FAQ is telling you so rather than leaving you to discover it.

An application that is also a script, with credentials on disk

The packaging is unusual and worth understanding before you install it. The project is published as a Python package with a console script, but it is built and distributed as a desktop application, and the repository carries the machinery for that: a compile.py script, an AppImageBuilder.yml, a msicreator directory for building the Windows installer, an msi_res directory for its resources, and a sticker-convert.appdata.xml for the software catalogue listings on Linux.

That explains the Docker stages. The GUI is a real windowed application, and the container runs it against a virtual display so you can reach it over VNC or the web interface, which is why port 5800 and the optional 5900 are in the compose file.

The credentials question is covered by its own FAQ entry on where they are stored, and the compose file hints at the answer with the commented mount of creds.json into the config directory. The uploads need real account credentials for the target service, and the tool asks for them per application.

The repository also has a docs/ directory with a per-application guide for every supported platform, in several languages, plus a dedicated entry for the cases the compatibility table flags. That is the right place to look for the specific credential flow, since each service has its own login dance.

Editorial conclusion

Adopt sticker-convert if you maintain a sticker library across several messaging apps and need the animated formats to be re-encoded for each one, since no app accepts another app's sticker format and the tool handles both directions. Do not adopt it expecting upload support everywhere, because Line, Kakao, Band, OGQ and Discord are download only and require manual approval, and iMessage is not supported for download at all. Before you rely on it, read the compatibility table and pick the credentials the app you need actually demands, such as a Telegram bot token and user_id, a Viber viber_auth, or Mastodon cookies, and note the release picture, where v2.21.0.2 shipped on 2026-10-15 with the last push on 2026-10-19.

Frequently asked questions

Official sources

1. Issues
2. laggykiller/sticker-convert on GitHub
3. License: GPL-2.0
4. README
5. Releases