# Czkawka 12.0 is the last GTK build, and the project you are actually being pointed at is Krokiet > The Czkawka repository holds three applications over one Rust core: Krokiet, a new Slint graphical frontend; Czkawka itself, the older GTK 4 frontend whose version 12.0 is the last release with new binaries; and Cedinia, an Android frontend for the same core. It also holds fourteen cleanup tools, a comparison table against three other applications, a build that deliberately unwinds panics instead of aborting, and an integration test harness that is excluded from the workspace. **qarmin/czkawka** — GitHub describes it as Multi functional app to find duplicates, empty folders, similar images etc.. The repository metadata lists Fluent as its primary language. The metadata lists the NOASSERTION license. This article stays within the project description and details documented in the GitHub repository README. - Repository: https://github.com/qarmin/czkawka - Stars: 33,845 · Forks: 1,193 - Language: Fluent - License: NOASSERTION - Published: 2026-08-13 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/qarmin-czkawka ## The repository is called Czkawka and the application you should install is Krokiet The first thing the README does is tell you that the name of the repository is not the name of the thing to install. There are three frontends over one core, and they have Polish names with pronunciations given in the text: Krokiet, which is a croquette, is the new generation graphical frontend, described as simple, multiplatform, fast and free. Czkawka, which is a hiccup, is the older GTK 4 frontend, and it is superseded by Krokiet. Then the sentence that decides your install: version 12.0 is the last released version, no new binaries will be provided, and both new and existing users are encouraged to switch to Krokiet. Cedinia is the third frontend, an Android touch friendly application for the same core, built with Slint. So there is a project still being worked on inside a repository whose name refers to a frontend that is finished. The releases list is consistent with that: 12.0.2 on 2026-09-09, 12.0.1 on 2026-07-29 and 12.0.0 on 2026-06-28, with the last push on 2026-09-16. If you arrived here searching for a duplicate file finder, the binary you want is not the one the repository is named after, and the README is unusually clear about that rather than leaving you to guess. ## Fourteen tools, and three of them are missing from the old frontend The tool list is the substance of the project. Duplicates, found by file name, size or hash. Empty Folders, using an advanced algorithm. Big Files, the largest files in a location. Empty Files. Temporary Files. Similar Images, which finds images that are not exactly the same because of a different resolution or a watermark. Similar Videos. Same Music, by tags or by reading the content and comparing it. Invalid Symbolic Links, pointing at things that no longer exist. Broken Files, invalid or corrupted. Bad Extensions, files whose content does not match their extension. Exif Remover. Video Optimizer, which crops static parts away and converts to more efficient formats. And Bad Names, files whose names may be ones you did not want, for example containing special characters. Then read the comparison table, because it is not a mirror of that list. The Exif cleaner row is marked for Krokiet and Cedinia and is blank for Czkawka. The Video optimizer row is marked for Krokiet only. Bad Names is marked for Krokiet and Cedinia and blank for Czkawka. So three of the fourteen tools do not exist in the old GTK frontend at all. That is a concrete reason the README gives for switching rather than a matter of taste: moving to Krokiet gains those three, and the table shows nothing that Czkawka has is missing from Krokiet. ## The comparison table admits that matching features are not the same feature The table sets Krokiet, Czkawka and Cedinia against three other applications, FSlint, DupeGuru and Bleachbit, and the README puts a caveat above it: even if applications have the same features they may work differently, for example one application may have more options to choose than another. That sentence is the most useful line in the whole file, because it tells you the check marks are a starting point. What the table shows is a clear division. The three Czkawka frontends and FSlint all have duplicate finding, empty file, empty folder and temporary file detection. All three Czkawka frontends and DupeGuru have similar images and music duplicate detection by tags. FSlint has things none of the Czkawka frontends have: names conflict, installed packages, bad ID, non-stripped binaries, redundant whitespace, and invalid symlinks alongside overwriting files, which Bleachbit also has. The honest summary is that Czkawka is strongest at duplicates, empty things, big files, similar media and broken or mislabelled files, and that a general disk hygiene pass covering installed packages or stripped binaries is a different job that this project does not claim. ## The release profile unwinds panics and keeps overflow checks on The workspace manifest has a release profile with three decisions and a comment explaining each one, which is more engineering detail than most projects publish about their build. The first is panic behaviour. The profile sets unwinding rather than aborting, and the comment says that Czkawka parses different types of files with a few libraries, so it is possible that some files will cause a crash, and that abort is not recommended until you are ready for occasional crashes. The practical meaning is that a malformed file produces a recoverable error rather than taking the process down, and that the maintainer has chosen that trade deliberately. The second is overflow checks, enabled in release, with a comment saying this should find more panics that are now hidden from the user, that it may cause some crashes which are not handled by catching them, and that you are free to disable it. So release builds are slower and slightly less stable on purpose, in exchange for surfacing arithmetic overflow that would otherwise corrupt a result silently. The third is link time optimisation, left off by default because release mode is usually needed to develop and compiling with it takes a long time, with fat LTO and a single codegen unit present but commented out and noted as generating a much smaller executable. Release builds you download are therefore not built the way a development build is. ## A commented-out Slint patch is sitting in the manifest with a reason attached Near the top of the workspace manifest there is a patch section for the crates registry, and every line of it is commented out. The heading comment says it is a temporary solution for spamming mouse events in Slint, and that even with the workaround performance is quite low in specific cases in Cedinia. What follows the comment is instructive. There are two kinds of override. One points at local filesystem paths under a home directory belonging to the maintainer, patching Slint, its build crate, and two lower level crates in its text stack. The other points at a git repository, patching the same Slint crates. A developer kept their own workaround in the file and left it disabled. So the Android frontend has a known input latency problem, the fix depends on changes to a third party toolkit, and the workaround is one edit away from being live. That is worth knowing before you recommend Cedinia for touch use, because the project's own manifest says the performance is still low in the cases it affects, and it also explains why the new graphical frontend is Slint at all. ## The integration tests live outside the workspace and download a corpus from 6.0.0 The build and test surface is a justfile rather than a Makefile, and it is more revealing than it looks. The default build target compiles a release build, a debug build, runs clippy and runs the tests. The integration test target is different: it downloads a file called TestFiles.zip from the project's 6.0.0 release if it is not already present, builds a separate crate called ci_tester in release mode, builds the command line frontend in release mode, and then runs one against the other with backtraces enabled. The ci_tester crate is listed in the workspace's exclude list, along with three performance directories and a test directory, so it is deliberately not part of the main workspace and does not get compiled when you build the project. There are also recipes for running under valgrind with full leak checking and origin tracking, and under the address sanitizer on a nightly toolchain, where leak detection is switched off with a comment saying it is slow and usually not needed. And the Android recipes need two environment variables set in your shell before they work at all, an SDK home and an NDK home, with the APK package name and a native activity recorded alongside them. ## MIT for the code, CC BY 4.0 for the icons, and no install command at the top Licensing here is two files rather than one, and the names say which is which: a licence covering everything outside any Cargo application or library, and a separate Creative Commons Attribution 4.0 licence for the icons. If you are redistributing the application, the icon set is the part with attribution obligations. The installation section is where this README is weakest, and the reason is stated: each tool uses different technologies, so the instructions are in five separate files, one for the Krokiet graphical frontend, one for the GTK frontend, one for the command line, one for the core library and one for Cedinia. The top level file contains no install command at all, which is a deliberate structure and a reasonable one, since a Slint application, a GTK 4 application, a CLI, a library and an Android app do not install the same way. Two operational claims are worth repeating because they shape expectations. Caching is supported, so the second and subsequent scans should be much faster than the first. And the project states that Czkawka has no access to the internet and collects no user information or statistics, which for a tool that walks your filesystem and deletes what you tell it to is a claim you will want to check against the build you actually run. The features list also names multithreading and efficient algorithms as the reason for speed, and a portable version as available for both desktop frontends. ## Conclusion Use Krokiet if you want the current application, and use czkawka_core if you want the library, because the GTK frontend has stopped and version 12.0 is the last one that will get binaries. Do not start a new deployment on the GTK build expecting updates, and do not assume the fourteen tools are in every frontend, because the comparison table shows Exif Remover, Video Optimizer and Bad Names exist only in Krokiet and Cedinia. Before you install: read the README for the frontend you actually want, since the top level file carries no install command and points to five per-tool guides; expect a first scan to be slower than later ones because caching is what makes repeat scans fast; and build with the justfile targets rather than guessing, because the integration harness lives outside the Cargo workspace and downloads its own test corpus. ## FAQ ### What is czkawka? It is a multi-functional application for removing unnecessary files, built in Rust and described as almost entirely free of unsafe code. It finds duplicates by name, size or hash, empty folders, big files, empty files, temporary files, similar images, similar videos, same music, invalid symbolic links, broken files, bad extensions, and it can strip Exif metadata and optimise video, with cache support so later scans are much faster than the first. ### How do I install Czkawka on Windows? The top level README carries no install command and says so, because each frontend installs differently and the instructions live in five separate files, one of which is the GTK frontend guide. New binaries are published on the GitHub releases page with nightly builds under a separate tag, but the GTK frontend stopped at version 12.0, so a new user should follow the Krokiet guide instead. ### how to use czkawka cli The command line frontend has its own README for instructions, listed in the top level file alongside the graphical frontends, the core library and the Android app. The features list describes a CLI frontend for easy automation, and the project is built around a reusable core library, so the CLI is one consumer of that core rather than the only entry point. ### how to use czkawka gui There are two graphical frontends and they are at different stages. The older GTK 4 one, Czkawka, is superseded: version 12.0 is the last released version and no new binaries will be provided. The current one is Krokiet, a Slint frontend, and the project's own comparison table shows it has everything the GTK build had plus Exif removal, video optimisation and bad name detection. ### What is the best duplicate file finder for Windows 11? The project's comparison table marks duplicate finding as available in Krokiet, Czkawka, Cedinia, FSlint and DupeGuru, and the README warns above the table that matching features may still behave differently and that one application may offer more options than another. FSlint is the one in that table with capabilities none of the Czkawka frontends claim, such as installed packages and non-stripped binaries. ### how to install czkawka on ubuntu The README states that the project is multiplatform and runs on Linux, Windows, macOS and FreeBSD on x86, ARM and RISC-V, and that the Krokiet and GTK frontends both have a portable version. It does not name Ubuntu specifically, and it carries no install command, so the frontend guide for the application you want is the document to follow. ## Sources - [Official README](https://github.com/qarmin/czkawka#readme) - [Project repository](https://github.com/qarmin/czkawka) - [Release notes](https://github.com/qarmin/czkawka/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/qarmin-czkawka