Flameshot: a Qt screenshot tool with an in-app editor and a DBus interface
Powerful yet simple to use screenshot software :desktop_computer: :camera_flash:
At a glance
- What is it?
- Flameshot is a GPL-3.0, C++/Qt screenshot application for Linux, Windows and macOS whose capture mode includes annotation tools and whose behaviour can be driven from the command line or over DBus. It is a good fit for desktop users and script authors who want a configurable capture step, and a poor fit where no desktop portal implements the Screenshot interface.
- Who is it for?
- Adopt Flameshot if you capture screenshots on a full desktop environment and want annotation, clipboard output and scriptable capture in one binary. Skip it on a minimal X11 window manager or a bare wlroots compositor until you have read docs/UsageX11MinimalWM.md and docs/UsageHyprlandSwayWlroots.md, because capture can fail with a portal timeout.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Flameshot fills between a compositor keybind and an image editor
A plain screenshot key in a desktop environment gives you a file and nothing else. Anything you want to do to that file, such as drawing an arrow, blurring a password field or cropping to one window, means opening a second application and re-importing the image. Flameshot puts the editing step inside the capture flow: the README lists "In-app screenshot editing" as a feature, and the graphical capture mode exposes shortcuts that the About window enumerates. The project is aimed at desktop users on GNU/Linux, Windows and macOS who take screenshots often enough that the round trip through an external editor is a nuisance, and at people who want that capture step callable from a script or a window manager keybind rather than only from a tray menu.
The secondary audience matters more than the README's framing suggests. Flameshot is not just a GUI application with a tray icon. It is a command-line program that happens to have a GUI mode, and the README's own advice for picking a keybind is to use `flameshot gui` or `flameshot full` as the shortcut target. The DBus interface listed under Features extends that further, letting other processes ask a running instance to act.
How capture, the editor and the tray process fit together
Running `flameshot` with no arguments starts an instance in the background and, where the desktop environment provides a tray area, places an icon there. That long-lived process is the thing the CLI subcommands talk to. The README describes the tray menu as the route to the configuration window and the information window, and the About window as the place where the capture-mode shortcuts are listed.
The subcommands split the work. `flameshot gui` captures with the graphical editor. `flameshot full` captures the whole screen with no GUI. `flameshot screen` captures a single screen, selected by number with `-n` or by the screen containing the mouse when `-r` is used. Output can go to a path with `-p`, to the clipboard with `-c`, or to standard output as PNG bytes with `-r`. Delays are expressed in milliseconds through `-d`, so `flameshot gui -d 2000` waits two seconds before capturing, which the README suggests for capturing mouse hover tooltips.
That split is the design decision worth noting. The GUI editor and the headless capture paths are separate code paths behind one binary, and a script that only ever calls `flameshot full -c -p ~/myStuff/captures` never touches the annotation UI at all. Configuration lives in a config file, with `flameshot config` opening the graphical menu for the same settings, and the README points at a CLI configuration route for people who would rather script it.
Commands and flags you will actually type
The README's example commands are the reliable starting point. `flameshot gui` opens the capture editor. `flameshot gui -p ~/myStuff/captures` sends the result to a directory of your choosing. `flameshot gui -d 2000` adds a two second delay. `flameshot full -p ~/myStuff/captures -d 5000` takes a full-screen capture after five seconds with no editor. `flameshot full -c -p ~/myStuff/captures` writes the file and copies it to the clipboard in the same run. `flameshot screen -r` captures the screen under the mouse and prints PNG bytes, which is the form you want when piping into another program. `flameshot screen -n 1 -c` captures screen number one straight to the clipboard.
On Windows there is a wrinkle the README calls out directly. `flameshot.exe` accepts the supported command-line arguments but writes nothing to the console, so even `flameshot.exe -h` produces no visible help text. The workaround is `flameshot-cli.exe`, described as a minimal wrapper around `flameshot.exe` that captures stdout and prints it. If you are writing a Windows script that parses Flameshot's output, you need the wrapper, not the main executable.
For configuration, `flameshot config` opens the graphical menu. The README's index also lists a CLI configuration section and a config file section, so settings can be changed without the GUI, but the supplied excerpt does not show the individual keys, so the exact key names are something to read from the file itself rather than guess at.
Where capture fails: Wayland compositors and bare X11 window managers
The README is unusually direct about the environments where Flameshot does not simply work. On Hyprland, Sway and other wlroots-based Wayland compositors, it defers to a separate document, docs/UsageHyprlandSwayWlroots.md, rather than describing the setup inline. That is a signal that the steps are non-trivial and compositor-specific.
The sharper failure is on minimal X11 window managers such as i3, dwm, xmonad and bspwm. There, the README states that capturing may fail because no portal backend implements the Screenshot interface, and it quotes the errors you would see: "Could not locate the org.freedesktop.portal.Desktop service" or "Screenshot portal timed out". The documented fix is to enable the legacy X11 capture path, again covered in a separate file, docs/UsageX11MinimalWM.md. This is the clearest case where Flameshot is the wrong tool out of the box: if your session has no portal implementing Screenshot, the default path cannot complete, and you are relying on a legacy fallback that the documentation treats as a workaround rather than the normal mode.
A second limitation is structural rather than environmental. The GUI editor and the tray process assume a desktop session. On a headless machine or over a bare SSH connection there is no tray, no capture mode and no editor, and the useful surface shrinks to whatever the non-GUI subcommands can do.
Flameshot against scrot and the desktop's own screenshot key
The natural comparison is scrot, the long-standing command-line X11 capture utility, and behind it the screenshot key that GNOME, KDE and XFCE already ship. The difference is where editing happens. scrot captures and writes a file; if you want an arrow or a blur on that image you open something else. Flameshot's `flameshot gui` puts the annotation tools in the same window as the selection, so the round trip disappears. That is the whole reason to prefer it, and if you never annotate, the advantage largely evaporates.
The desktop's built-in screenshot key is a different trade. It is already bound, already integrated with the compositor, and needs no extra process. Flameshot's counter is configurability: custom save paths, millisecond delays, clipboard output, per-screen selection, PNG on stdout and a DBus interface. The README's keyboard shortcut section goes further and documents how to bind Flameshot globally on KDE Plasma, GNOME, XFCE 4 and Fluxbox, which tells you the project expects to replace the built-in key rather than sit beside it. The cost of that replacement is one more background process and one more thing that can fail to start with your session.
Against scrot specifically, the trade is binary size and dependency weight. Flameshot is a Qt application with a GUI, a tray icon and a DBus interface; scrot is a small X11 utility. If your only need is a file on disk from a script, the smaller tool is the better fit, and Flameshot's extra surface is cost without benefit.
Building it, packaging it and keeping it current
Flameshot is written in C++ and uses Qt, and the README splits its dependencies into compile-time, run-time and optional groups, with per-distribution instructions for Debian, Fedora and Arch. The optional group is worth reading before you build, because features such as upload to Imgur and the DBus interface may depend on libraries you would otherwise skip. Prebuilt packages exist: the README links the Snap Store and Flathub badges, and separate installation sections cover macOS and Windows. If you are on a mainstream distribution, installing a package is the sensible default and compiling is the fallback.
The release cadence visible in the repository shows v14.0.0 tagged on 2026-06-19, preceded by v14.0.rc3 on 2026-06-01 and v14.0.rc1 on 2026-04-06. That is a release-candidate cycle of roughly two and a half months before the final tag, which suggests the project does not ship a stable major version without a testing window. Nightly builds are advertised through a badge pointing at the development build page. If you depend on a specific flag or a Wayland fix, tracking the nightly channel is the way to get it early, at the cost of running unreleased code.
Upgrade cost is mostly packaging cost. There is no server component and no database schema, so an upgrade is replacing a binary and, occasionally, re-reading the config file section if a key changed. The real maintenance burden is environmental: a desktop session change, a switch from X11 to Wayland, or a new window manager can invalidate a working configuration without any change to Flameshot itself.
Licence, privacy and code signing in plain terms
Flameshot is licensed GPL-3.0. For an individual running it on a personal machine, that is unremarkable. For a company that wants to bundle the binary into a product, modify it and ship it under different terms, the GPL-3.0 copyleft obligations apply to the distributed work, and that is a question for your own legal review rather than something to settle from a README. The repository also carries a privacy policy and a code signing policy as top-level sections, which is relevant if you are installing a prebuilt binary and want to know how it is signed and what data, if any, leaves the machine. The README lists upload to Imgur as a feature, so if that path is used, image data goes to a third-party service; the details are in the privacy policy, not in the excerpt available here.
Editorial conclusion
Adopt Flameshot if you capture screenshots on a full desktop environment and want annotation, clipboard output and scriptable capture in one binary. Skip it on a minimal X11 window manager or a bare wlroots compositor until you have read docs/UsageX11MinimalWM.md and docs/UsageHyprlandSwayWlroots.md, because capture can fail with a portal timeout. Before rolling it out, verify that `flameshot gui` opens the editor on your actual session, that your package is at v14.0.0 or later, and that the GPL-3.0 terms are acceptable for how you intend to redistribute the binary.
Community notes