Greenshot: a Windows screenshot tool built for people who take a lot of screenshots

The problem Greenshot solves is capture plus routing, not capture alone

Windows has had a built-in screen capture path for years, so the interesting question about Greenshot is not whether it can grab a rectangle of pixels. It can, and so can the system tool. The problem it targets is what happens after the grab.

The README lists the capture modes first: a selected region, a window, or the full screen. Then it lists what you can do to the result: annotate, highlight or obfuscate parts of the image. Then it lists destinations: save to file, send to printer, copy to clipboard, attach to e-mail, send Office programs, or upload to photo sites such as Flickr or Picasa.

That third list is the actual product. A screenshot tool that stops at the clipboard forces you to open an editor, then a mail client, then a file dialog. Greenshot's stated purpose is to collapse those steps into one flow, which is why the README describes it as "optimized for productivity" and names project managers, software developers, technical writers and testers as the intended users. Those are roles where a screenshot is usually an artefact that has to reach someone else, often with an arrow drawn on it.

If your screenshots end up in a bug tracker, a spec document or a chat message, the routing layer is the part worth evaluating. If they end up nowhere, the built-in tool is probably enough.

How Greenshot is put together: a C# application on .NET Framework 4.8

The repository is a C# codebase under a src/ directory, with a solution file at src/Greenshot.sln. The build instructions state that Greenshot is built using .NET Framework 4.8.0, and that any version between 4.8.0 and 4.8.1 will suffice. That is a Windows-only target, which matches the project's description of itself as screenshot software for Windows.

Around the source tree sit the pieces you would expect from a desktop application that has to reach users outside a development environment: an installer/ directory, a chocolatey/ directory, and a prepare-portable.ps1 script at the top level. There is also a build-and-deploy.ps1 script, which suggests the release pipeline is PowerShell-driven rather than handled entirely by the IDE.

The README points developers at Visual Studio 2022 or newer, and notes that .NET SDK 9.0.311 is also required for building. That combination is worth reading carefully: the application runs on .NET Framework 4.8, while the build tooling wants a much newer SDK. Anyone setting up a build machine needs both, and the README does not describe a command-line-only build path. The documented route is to open the solution in Visual Studio and use Build, then Build Solution.

One top-level file, TEXT_OBFUSCATION_FEATURE.md, sits outside the source tree. The README mentions obfuscation as a feature but does not explain the mechanism; that file is where the explanation presumably lives.

Building Greenshot from source in Visual Studio 2022

The README's instructions are written for contributors rather than end users, and they assume a Windows machine with the prerequisites already in place. The stated requirements are .NET Framework 4.8.0 through 4.8.1, Visual Studio 2022 or newer, and .NET SDK 9.0.311.

Start by cloning the repository, or downloading it and opening the solution file directly. The README gives the path explicitly.

git clone https://github.com/greenshot/greenshot.git
cd greenshot

Once the repository is on disk, open the solution in Visual Studio. The README says you can either clone through Visual Studio using the link in the green code button, or open the solution file from the downloaded copy. On the command line, that file is:

src/Greenshot.sln

With the solution open, choose Build, then Build Solution. The README's next step is a verification step rather than a run step: confirm that all components built successfully. Only then does it say you are ready to contribute.

There is no documented run instruction, no sample configuration file and no command-line invocation in the README. If you want to use Greenshot rather than modify it, the README does not send you to the source tree at all. It points to the downloads page on the project website, which it says always links to the latest stable release, and to the GitHub releases list and the version history page for the full set of stable and unstable builds.

The continuous builds are not the stable release

The releases list on the repository is dominated by tagged continuous builds, named in the form v1.4.242-g6acea74cc0 with the suffix "continuous build" attached. Several of these appear within a single day. That cadence is normal for a development branch, and the README is explicit that this repository is "the ongoing development branch for future Greenshot releases."

The practical consequence is that a GitHub release page is a poor place for an end user to pick a download. The README separates the two channels on purpose: GitHub releases and the website version history cover both stable and unstable builds, while the downloads page is described as always linking to the latest stable release. If you are deploying Greenshot to a team, the downloads page is the reference point, not the most recent tag.

This is also where the repository's maintenance picture matters. The last push to the main branch was on 2026-09-22, and the most recent tagged build carries the same date. The project is not archived. If you are evaluating whether the codebase is alive, the commit dates answer that question directly; the README's contributor instructions, which ask for small and concise commits and a pull request for review, describe a project that still expects outside patches.

Where Greenshot is the wrong tool

The clearest limitation is the platform. Greenshot is Windows software, and the build requirements confirm it: .NET Framework 4.8 and a Windows OS environment. There is no macOS or Linux build documented anywhere in the README, and the project description says "for Windows" without qualification. If your team is mixed-platform, Greenshot covers only part of it, and you will need a second tool for the rest.

The second limitation is architectural. Greenshot is a desktop application distributed through an installer, a Chocolatey package and a portable script, not a service. There is no documented server component, no API and no headless mode in the README. That rules it out for automated screenshot capture in a CI pipeline, for capturing a remote machine you cannot sit in front of, and for any workflow where the capture has to be triggered by something other than a person pressing a key.

The third is the obfuscation feature. The README lists obfuscation alongside annotation and highlighting, and a separate top-level file, TEXT_OBFUSCATION_FEATURE.md, exists for it. The README itself does not describe how the obfuscation works or what guarantees it gives. Anyone planning to use Greenshot to redact sensitive information before sharing an image should read that file rather than assume the result is irreversible. The README does not make that claim.

Finally, the licence. Greenshot is GPL-3.0. That is fine for internal use, but it constrains redistribution and embedding in a closed product. The README does not discuss licence obligations for downstream users, so that analysis is on you.

Greenshot compared with the Windows Snipping Tool

The obvious alternative is the Snipping Tool that ships with Windows. The comparison is not about capture quality; both take a rectangle, a window or the full screen. The difference is in what each tool assumes about the next step.

The Snipping Tool assumes the screenshot is the end of the task. You capture, you get an image, you save it or copy it. There is markup, but the tool is built around producing a picture.

Greenshot assumes the screenshot is the start of a task. The README's feature list is dominated by destinations: printer, clipboard, e-mail attachment, Office programs, photo sites. Annotation and obfuscation exist to prepare the image for one of those destinations. That is a different centre of gravity, and it is why the README frames the tool around productivity and names roles that produce screenshots as part of a workflow.

The trade-off is real in both directions. The Snipping Tool requires no installation, no .NET Framework version check and no third-party download, which matters if you are cautious about what you install. Greenshot requires an installer or a Chocolatey package and a Windows machine with the right framework version, and it carries a GPL-3.0 licence. In exchange you get the routing and annotation features that the built-in tool does not attempt to cover.

Licence, maintenance and the cost of staying current

Greenshot is licensed under GPL-3.0. The full text sits in the LICENSE file at the top level of the repository. The practical implication for most readers is that using Greenshot internally, at work or at home, is not the interesting question. The interesting question is what happens if you redistribute it, bundle it with something else, or modify it. GPL-3.0 has conditions attached to those activities, and the README does not summarise them. That is a question for your own legal review, not for this article.

Separately from the code licence, the README contains a trademark and logo usage policy. The Greenshot name and logo belong to the development team, and the README permits their use in blog posts, articles and reviews that discuss the project, and in educational materials, provided the usage is fair and does not imply endorsement. Promotional materials and products need prior written permission. This is a distinct restriction from the software licence and applies even to people who never touch the source.

On maintenance, the concrete facts are that the repository is not archived and the last push was on 2026-09-22. Continuous builds are tagged frequently, and the README describes this branch as the development branch for future releases. The upgrade cost for a user is low: the README points to a downloads page that always links to the latest stable release, so staying current means revisiting that page rather than tracking tags. For a contributor, the cost is higher, because the build requires Visual Studio 2022 or newer plus .NET SDK 9.0.311 alongside the .NET Framework 4.8 runtime target, and the README documents no build path that avoids the IDE.

Editorial conclusion

Adopt Greenshot if your working day involves capturing Windows screens, marking them up and sending them somewhere, and you are willing to run a GPL-3.0 desktop application. Do not adopt it if you need macOS or Linux, or if you want a tool with no installation step. Before committing, check the downloads page at getgreenshot.org/downloads for the current stable release, since the repository's own continuous builds are not the same artefact, and confirm the .NET Framework 4.8 requirement against your Windows images.

Frequently asked questions

Official sources

1. greenshot/greenshot on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases