uTox: a small C client for the Tox messenger network

A graphical shell over toxcore, and what that means

uTox is described as the lightweight Tox client, and the design is clearer once you notice what the repository does and does not contain.

Tox is a peer-to-peer, end-to-end encrypted, instant messaging protocol, with end-to-end encryption as its default and only mode. The protocol implementation is [toxcore](https://github.com/TokTok/toxcore), and uTox is the user interface on top of it. The repository links the toxcore project, the TokTok site and the Toxcore specification, and the primary language is C.

So the scope is a native graphical client, not a protocol stack. It talks to toxcore, and toxcore handles the cryptography, the peer-to-peer connections and the protocol itself. That split has an important consequence for anyone evaluating the project: the security properties come from toxcore, and uTox is the part you would be reading if you wanted to understand how a desktop messenger is put together in C.

The feature list is the standard messenger surface. Themes and avatars. Text with chat history. Audio. Video, either webcam or desktop sharing. Screenshots. File transfers with inline images support. Group chats with text. And Tox URI support, meaning clickable Tox links in the chat.

What is absent is as informative as what is present. There is no plugin system, no scripting, no extension model, no headless mode and no command line interface. It is a desktop messenger that does messaging, and it does not try to be a platform.

The last push was on 2026-10-14, the default branch is `develop`, and the newest tagged release is v0.18.1 from 2021-01-23, with v0.18.0 from 2020-11-27 and v0.17.2 from April 2020. The repository is being worked on well after the last tag, which is a normal pattern for a project that tags releases infrequently.

The status of the project is stated in the first paragraph of the FAQ

The readme does not oversell the state of the project, and the paragraph that sets expectations is worth reading in full.

Just like Toxcore, µTox is still alpha software, so you may encounter bugs, or maybe a crash or two. µTox also needs your help, and if you do encounter any bugs or problems you should open an issue. If you do not have a GitHub account, you may also send an email.

That is a candid framing from a project with a long history. It is also the reason the readme asks for help rather than presenting a stable client, and it explains why the release tags stopped in 2021 while the commits continued.

The platform support statement is equally direct. uTox is cross-platform, with primary support for Windows 7 and later and Linux, and secondary support for OpenBSD, FreeBSD, NetBSD and DragonFlyBSD. MacOS is currently broken and unmaintained, and if you have a Mac and are interested in contributing, the readme points you at the team.

The team list is four people with GitHub, IRC, email and a fingerprint for each, and the fingerprints are given as the standard PGP key blocks. For a privacy-focused messenger, publishing the fingerprints is not decoration, because it is how a user verifies that the binary they downloaded was signed by the person they think signed it. The former maintainers are listed separately as cebe, dkmoz and avoidr.

The translations are a real asset rather than a footnote. Complete translations exist for German, Russian, Swedish, Polish, Spanish, Hungarian, Estonian, Ukrainian and Bulgarian, with partial translations to many more, and the `langs/` directory at the root of the repository is where they live.

Downloads, and a macOS build that has been abandoned since 2020

The downloads section is short and it tells you exactly where the project still delivers.

For Windows there is a 64-bit executable linked directly from the release, `utox_x86_64.exe` on the v0.18.1 tag. For Linux and other POSIX systems the instruction is to install via your package manager or build it yourself, pointing at the install and build documentation. For macOS there is a disk image, and the parenthetical is the important part, Last Updated.dmg, and it links to v0.16.1 with the note out of date.

So the macOS build is two minor versions behind the Windows one and is explicitly flagged as stale. Combined with the statement in the features section that macOS is broken and unmaintained, the picture is consistent: the macOS client is a build artefact from an earlier era that is still linked because deleting the link would only frustrate people who find it.

The Unix situation is different, and it is the reason the project lists four BSDs as secondary support. Installation is through your package manager or a build from source.

The documentation directory holds the install instructions, the build instructions, the screenshots index and the release notes, and the release notes have their own index at `release_notes/INDEX.md`. A project that keeps a per-release notes archive rather than a single changelog has usually made a decision about how users should read about changes, and for a client with a long history across many platforms it is the right call.

The repository layout is a complete C application with its own conventions

The top-level listing shows what a long-lived C project accumulates, and the `.clang-format` at the root is a small sign of a project with formatting settled rather than argued about.

There is a `CMakeLists.txt` and a `cmake/` directory, so the build is CMake, and there is a `src/` directory with the C sources, `third_party/` for vendored dependencies, and `tests/` for the test suite. The `.gitmodules` file confirms the vendored components are submodules rather than copies, which means they can be updated independently.

The `tools/` directory is where the developer tooling lives, and `extra/` is a conventional name for the things that do not belong in the main source tree. There is a `man/` directory for the manual page, `icons/` for the artwork, and `langs/` for the translations. The `.mailmap` file is the one that only shows up in repositories with real contributors, since it maps commit authors to a canonical identity and keeps the history clean when people change their email address or their name.

The `CHANGELOG.md` at the root coexists with the `release_notes/` directory, which is a common pattern: the changelog for the current cycle, the release notes for the history.

The build badge points at a GitHub Actions workflow on the `develop` branch, and the IRC badge points at `#utox` on libera.chat. Both matter for a project of this kind, because a messenger client is not much use if the people you want to talk to are not on the network, and the network's health is a community question rather than a code one.

Where uTox is the wrong choice

The first case is a macOS user, and there is no ambiguity about it. The readme says macOS is currently broken and unmaintained, and the linked disk image is from v0.16.1, two releases behind the current Windows build. The protocol may have moved on since then, and an old client talking to a new network is a bad combination.

The second case is a user who wants a modern messaging client with a plugin ecosystem, themes from a community, or a rich notification and search experience. uTox's feature list is complete for a basic messenger and stops there, and there is no extension mechanism to fill the gaps. A client with a large theme catalogue or a plugin API is a different product, and it will be written in a different way.

The third case is a team that needs a maintained release train. The newest tagged release is v0.18.1 from January 2021, and while the repository is being actively worked on, a tag that old means there is no obvious artefact to install for a current build, and no changelog entry to read to find out what changed. For a client where a protocol change could break compatibility, the gap between the last tag and the current tree is a question you have to answer by reading the commit log.

The fourth is a deployment that needs the client to talk to a specific toxcore build. Because uTox is a thin layer, the version of toxcore it links against matters, and the `third_party/` directory and submodules mean the pairing is something you control rather than something the package manager picks for you.

One practical note on the security model, which is a strength rather than a limitation. Tox has end-to-end encryption as its default and only mode, and the client publishes the maintainers' PGP fingerprints so that the binary can be verified against a known identity. For a messenger, being able to check who signed the build you are running is more than a nicety, and the fact that the fingerprints are in the readme rather than on a separate key server page is a reasonable place for them to be.

Editorial conclusion

uTox fits a Linux or Windows user who wants a small, unobtrusive Tox client and is comfortable with a project that still calls itself alpha, and it fits a developer who wants to read a complete graphical client for toxcore in C. It does not fit a macOS user, where support is described as broken and unmaintained, and it does not fit someone who needs a maintained release cadence, since the newest tagged release is v0.18.1 from January 2021 even though the repository is still being worked on. Before you install, read the release notes for your platform and check whether the packaged toxcore version matches what the client expects, since the client is a thin layer over a protocol implementation that changes independently.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. uTox/uTox on GitHub