# ksnip: a Qt screenshot tool that outgrew its single maintainer

> Cross platform screen capture with an annotation layer, six packaging formats for Linux, and a Wayland support matrix that documents its own gaps.

**ksnip/ksnip** — ksnip the cross-platform screenshot and annotation tool

- Repository: https://github.com/ksnip/ksnip
- Stars: 3,355 · Forks: 246
- Language: C++
- License: GPL-3.0
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/ksnip-ksnip

## A capture tool first, an annotation editor second

The README describes ksnip as a Qt-based cross-platform screenshot tool that provides many annotation features for your screenshots, and the feature list is organised along those two lines. On the capture side there is a rectangular area drawn with the mouse cursor, a repeat of the last selected rectangle, the current monitor, all monitors, the focused window, the window under the cursor, and capture with or without the pointer. Customizable capture delay applies to all of them, and global hotkeys are listed for Windows and X11 only.

The annotation side is closer to a small image editor than a markup overlay. There are pen, marker, rectangles, ellipses and text tools, stickers with custom sticker support, vertical and horizontal slicing, blur and pixelate for obfuscating regions, and image effects covering drop shadow, grayscale, inverted colour and border. Screenshots can also be printed or written to PDF or PS, and watermarks can be applied.

Uploading is a first-class feature rather than an afterthought. The list covers imgur in anonymous or user mode, FTP in anonymous or user mode, and arbitrary user-defined scripts. That is a screenshot tool designed for the bug report workflow, where the image needs to end up somewhere other than your own disk.

## The Wayland story told as a support matrix

The most useful thing in this repository is a table that documents where capture modes do not work. It lists eight capture types across seven environments, and the gaps are the point.

Under X11 nearly everything is available except the screenshot portal. Under Plasma Wayland you get full screen, current screen, window under cursor and capture without the mouse cursor, but no rectangular selection and no focused window capture. Under GNOME Wayland below version 41 the picture matches X11 closely. Windows matches X11. macOS has rectangular, last rectangle, full screen and current screen, but no window captures at all.

The portal row is the interesting one. The README explains that xdg-desktop-portal screenshots are taken by the compositor and passed to ksnip, that a popup dialog requiring extra confirmation appears, and that the implementation varies by compositor. It then states the limitation plainly: Snaps and GNOME Wayland at version 41 or above only support portal screenshots, and non-native screenshot tools are not allowed to take screenshots any other way.

That last sentence is the real constraint on Wayland. It is not that ksnip failed to implement native capture, it is that the platform forbids it, so on a modern GNOME desktop the rectangular selection feature simply is not available to any third party application. Reading this table before choosing ksnip for a GNOME workflow saves a lot of confusion.

## Six Linux packaging formats and a continuous build

Binaries are downloaded from the releases page, and the list covers RPM, DEB, APT, Snap, Flatpak and AppImage for Linux, a zipped EXE for Windows, and an APP inside a DMG for macOS. Each has its own one or two line install snippet, and the AppImage path is the shortest:

```bash
$ chmod a+x ksnip*.AppImage
$ ./ksnip*.AppImage
```

The DEB and RPM equivalents are just as short, using the package manager directly.

Above the tagged releases sits a release called Continuous build, published on the same cadence as pushes, and the README describes it precisely: all supported binaries are built for every pushed commit, the artifacts are not fully tested, and in most cases they are work in progress. That entry in the release list is dated 2026-09-07, which is also the repository's last push date.

This is the mechanism that reconciles the two ends of the project's release history. A reader who installs from the continuous build gets the current state of the code; a reader who installs a tagged release gets v1.10.1, which was published on 2023-03-15. The README header meanwhile states the version as v1.11.0, so the current development line is a version ahead of anything formally released and cut from that.

## A solo maintainer asking for help in public

The most consequential paragraph in the README is not about screenshots. Under a heading about looking for a co-maintainer, the maintainer writes that after many years of maintaining ksnip as a solo project, he has reached a point where he can no longer dedicate the amount of time the project deserves. He asks for contributors interested in a more active role covering feature work, bug fixes, releases and overall project direction, and says he is not stepping away completely and will remain available for guidance, discussions, code reviews and support.

The repository state is consistent with that account rather than with abandonment. The project is not archived, 3,329 stars and 245 forks, with a last push on 2026-09-07 and a continuous build published the same day. A project in crisis does not usually keep a build pipeline green on every commit.

The open issue count is the number to weigh. At 340 open issues against that star total, ksnip is carrying a visible backlog, which is what a solo-maintained desktop application with many platform combinations tends to accumulate. The repository structure supports the picture of real engineering rather than a thin wrapper: `src/`, `tests/`, `translations/` with a Weblate badge in the README, a `cmake/` directory, a `.gitmodules` for vendored libraries, and packaging definitions under `desktop/` and `snap/`.

## Scripting capture from the command line

The README lists command-line support for capturing screenshots and saving to a default location, filename and format, along with user-defined actions for taking a screenshot and post-processing it. The filename side is more capable than that summary suggests, because ksnip supports wildcards for year, month, day and time, plus a counter expressed as multiple hash characters that produce a zero-leading padded number.

Two earlier releases show how the scriptable surface grew. v1.10.0 added setting the image save location on the command line, FTP upload, uploading an image via the command line without opening the editor, debug logging, and a multi-language comment option in the desktop file. v1.10.1 was entirely fixes, among them drag and drop not working with snaps and loading an image from stdin on the single instance client runner side.

Single instance behaviour is the detail that makes the command-line story usable rather than annoying. The README describes running as a single instance application where secondary instances send their CLI parameters to the primary instance. Combined with a hotkey, that means a keybinding can trigger a capture and an upload without a window ever appearing, which is the arrangement that makes ksnip usable from a tiling window manager workflow.

## Reading the OCR and plugin claim carefully

OCR support is listed as coming through a plugin, with a parenthetical limiting it to Windows and Linux or Unix. That is a narrower statement than it first appears, since it is the only feature in the list with an explicit platform restriction beyond the capture matrix, and it arrives with the annotation tools rather than the capture pipeline.

The same restraint applies elsewhere in the feature list. Capturing the mouse cursor as an annotation item is described as something that can be moved and deleted, which is a small but telling detail: rather than baking the cursor into the pixels, ksnip adds it as an editable object. Tabs for screenshots and images, opening existing images by dialog, drag and drop or clipboard paste, and pinning screenshots in frameless windows that stay above other windows round out the window management side.

The honest summary is that ksnip is a mature tool on X11 and Plasma, a competent but constrained tool on modern GNOME and Wayland generally, and a project whose future depends on whether the co-maintainer search in the README succeeds. Nothing in the repository suggests it is unmaintained today.

## Conclusion

ksnip remains a capable capture tool, particularly on X11 and Plasma where every capture mode in the README's matrix is available, and its packaging breadth for Linux is better than most projects of this size manage. The two facts that should shape a decision are the maintenance situation the README states outright, a long-serving solo maintainer actively looking for co-maintainers, and the release gap between the version in the README and the newest tagged release on the releases page. If Wayland on GNOME is your environment, read the portal caveat before anything else; if you want an annotation editor and can install a Flatpak or an AppImage, the rest of the feature set speaks for itself.

## FAQ

### Which capture modes are available on GNOME Wayland?

Under GNOME Wayland below version 41 the README's matrix shows rectangular area, last rectangle, full screen, current screen, focused window, capture without the mouse cursor and screenshot portal all available. From version 41 onward only the portal route works, because the README states that non-native screenshot tools are not allowed to take screenshots any other way. Portal captures are made by the compositor and require an extra confirmation dialog.

### What is the difference between a tagged ksnip release and the continuous build?

The continuous build produces all supported binaries for every pushed commit, and the README states that these artifacts are not fully tested and are in most cases work in progress. A tagged release is the tested option. The newest tag on the releases page is v1.10.1 from March 2023, while the continuous build entry is dated September 2026, so the two differ by a full development line.

### Does ksnip upload screenshots anywhere by itself?

Yes, three ways, all listed in the feature section. Screenshots can go to imgur.com in anonymous or user mode, to an FTP server in anonymous or user mode, or through custom user defined scripts. FTP upload and command-line upload without opening the editor both arrived in v1.10.0, and there is also a command-line path with filename wildcards for dates and a zero-padded counter.

### Is ksnip still being maintained?

The repository is not archived and its last push was 2026-09-07, the same day a continuous build was published. At the same time the README carries a section where the long-serving solo maintainer explains he can no longer dedicate the time the project deserves and is looking for one or more co-maintainers, while saying he is not stepping away and will stay available for guidance and reviews.

### How do I install ksnip on Linux?

Six formats are published for Linux: RPM, DEB, APT, Snap, Flatpak and AppImage. The DEB installs with the apt package manager against a local file, and the AppImage needs to be made executable and then run in place. The README also flags a practical consequence of the Snap and Flatpak builds, since portal-only capture on GNOME applies to them.

## Sources

- [Issues](https://github.com/ksnip/ksnip/issues)
- [ksnip/ksnip on GitHub](https://github.com/ksnip/ksnip)
- [License: GPL-3.0](https://github.com/ksnip/ksnip/blob/master/LICENSE)
- [README](https://github.com/ksnip/ksnip/blob/master/README.md)
- [Releases](https://github.com/ksnip/ksnip/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ksnip-ksnip