Pinta: The GTK Paint Program for Linux, Windows and macOS

What Pinta is, and who the Paint.Net clone is for

Pinta describes itself in the README as a "GTK clone of Paint.Net 3.0", with support for Linux, Windows and macOS. That one line sets the scope. This is not a general-purpose raster editor competing on filter count or colour management. It is a reimplementation of a specific 2000s-era Windows editor's interaction model on top of GTK, so the people it suits are those who liked that model and want it on a Linux desktop.

The repository is C# throughout, split into Pinta.Core, Pinta.Effects, Pinta.Tools, Pinta.Gui.Widgets, Pinta.Docking and Pinta.Gui.Addins. That layout tells you the extension points: effects, tools and dockable panels are separate assemblies, and there is an add-in assembly as well. If you are evaluating Pinta as a platform rather than an application, those directories are where to look. The README does not document the add-in API, so treat that as unexplored until you read the source.

Pinta is not archived, and the last push was on 2026-09-21. The 3.1.2 release is dated 2026-04-02, following 3.1.1 on 2026-01-10 and 3.1 on 2025-12-24. That is a steady cadence across the 3.1 line, and the CHANGELOG is the place the project points readers for notable changes per release.

How Pinta is put together: GTK4, libadwaita and .NET 10

The build requirements are the clearest statement of the architecture. Linux needs gtk >= 4.18 and libadwaita >= 1.8, plus .NET 10. The README lists webp-pixbuf-loader as an optional dependency, which means WebP support arrives through the GTK pixbuf loader chain rather than through code compiled into Pinta itself. If that loader is missing, the application still builds; the format support is what changes.

On macOS the same stack comes from Homebrew: dotnet-sdk, libadwaita, adwaita-icon-theme, gettext and webp-pixbuf-loader. The README adds a detail that trips people up on that platform: DYLD_LIBRARY_PATH must point at /opt/homebrew/lib on Apple Silicon or /usr/local/lib on Intel, otherwise Pinta cannot load the GTK libraries. That is a runtime environment variable, not a build flag, so it has to be set in whatever launches the binary.

On Windows the GTK side comes from MSYS2 rather than from a native Windows GTK installer. The README directs you to the CLANG64 terminal and a pacman command that pulls mingw-w64-clang-x86_64-libadwaita and mingw-w64-clang-x86_64-webp-pixbuf-loader. For ARM64 Windows the same instructions apply from the CLANGARM64 terminal with clang-aarch64 substituted for clang-x86_64. This is the least conventional part of the whole setup: Windows users are expected to have an MSYS2 installation present before Visual Studio or the .NET SDK can produce a working binary.

The privacy statement in the README is short and worth quoting in substance: the program will not transfer information to other networked systems unless the user or the person installing it specifically requests it. For an offline image editor that is the expected posture, and it is stated rather than assumed.

Installing Pinta on Linux, Windows or macOS

Most users should not build Pinta at all. The README leads with two distribution channels: Flathub, where the application ID is com.github.PintaProject.Pinta, and the Snap Store. If your desktop supports Flatpak, that is the path with the fewest moving parts, because the GTK and libadwaita versions are supplied by the runtime rather than by your distribution.

For a source build on Linux, the README gives two options. The first is for development and testing, and it is two commands from the repository root:

dotnet build
dotnet run --project Pinta

The second is for installation, and it goes through the autotools wrapper rather than through dotnet publish:

./autogen.sh
make install

The README notes that if you are building from a tarball you run ./configure instead of ./autogen.sh, and that --prefix=<install directory> redirects the install away from /usr/local. Before either option, the distribution packages have to be present. The README's Ubuntu 22.10 example is:

sudo apt install autotools-dev autoconf-archive gettext intltool libadwaita-1-dev

On macOS the dependency step is a single Homebrew line, and then the same dotnet commands as Linux:

brew install dotnet-sdk libadwaita adwaita-icon-theme gettext webp-pixbuf-loader
dotnet build
dotnet run --project Pinta

On Windows, install MSYS2 first, then from the CLANG64 terminal run the pacman command the README gives, and afterwards open Pinta.sln in Visual Studio with .NET 10 selected in the installer. The command-line equivalent is again dotnet build followed by dotnet run --project Pinta.

For containerised development the README does not describe a Dockerfile of its own. It points at a separate project, pinta-virtual-dev-environment, and says to follow that project's instructions. Anyone expecting a docker run line in this repository will not find one.

Where Pinta is the wrong tool

The README is a build and contribution document, not a feature reference. It does not enumerate supported file formats beyond what the optional webp-pixbuf-loader implies, does not describe layer handling, and does not document a scripting or batch interface. If your workflow depends on any of those, you cannot confirm support from this repository's front page, and you should not assume it.

The build requirements are also a real constraint rather than a formality. GTK 4.18 and libadwaita 1.8 are recent minimums. On a long-term-support distribution that ships older GTK, the packaged build is the only realistic route, and if no package exists for your distribution the source build will fail at the dependency step before it reaches any Pinta code. The README's own Linux instructions are written against Ubuntu 22.10 and say only that other distributions should be "similar".

Windows is the weakest documented path. Requiring MSYS2 and a pacman invocation to supply libadwaita means the Windows build is not self-contained, and the README offers no installer instructions beyond the code-signing note that free signing is provided through SignPath.io. If you want a Windows binary without a toolchain, the honest answer from this material is that the README does not tell you where to get one.

Pinta against Krita and GIMP: different jobs

The obvious comparison is GIMP, and the difference is scope rather than quality. GIMP is a full raster editor with its own plugin ecosystem and scripting interfaces; Pinta is a clone of Paint.Net 3.0, which was always a lighter editor with a simpler tool set. Choosing Pinta means choosing the smaller surface deliberately, usually because you want a fast editor for crops, annotations and simple compositing on a GTK desktop rather than a program you learn over weeks.

Krita is the other reference point, and it points in a different direction again: painting and illustration rather than photo-style editing. Pinta's topics list on the repository includes painting and drawing alongside image-editor, so the project does not disclaim that audience, but the README's own framing is the Paint.Net clone, and Paint.Net was never a brush engine.

The more precise difference is the toolkit. GIMP and Krita each carry their own cross-platform UI stack. Pinta uses GTK4 and libadwaita, so on a GNOME desktop it inherits the system theme, the icon theme and the file chooser instead of shipping its own. That integration is the reason to pick it, and it is also the reason the dependency floor is high: you are buying into the GTK release cycle.

Licence, maintenance and what an upgrade costs

Pinta's original code is MIT, and the repository carries license-mit.txt. The complication is that code from Paint.Net 3.36 is also used under the MIT License and retains the original headers on source files, with Paint.Net's own licence in license-pdn.txt. The README points you at both files. The icons add a third layer: Paint.Net 3.0 icons under MIT, the Silk and Fugue icon sets under Creative Commons Attribution 3.0, and contributor icons under the project's own licence, listed in Pinta.Resources/icons/pinta-icons.md. If you redistribute Pinta or reuse its assets, the attribution obligations are not uniform across the tree. That is a factual observation about the repository, not legal advice; read the files.

Upgrade cost is bounded by the release cadence. Three releases landed between 2025-12-24 and 2026-04-02, and the README directs readers to the CHANGELOG for notable changes per release. The last push to the repository was on 2026-09-21, so the codebase is moving between releases as well. For a packaged install, an upgrade is whatever your Flatpak, Snap or distribution channel does. For a source install, it is the same autogen, make install sequence again, and the dependency floor can move with it, since GTK 4.18 and libadwaita 1.8 are stated as minimums rather than pinned versions.

There is a patch-guidelines.md in the repository for people sending changes, and translation happens on Weblate rather than in pull requests. The README lists technical help and ideas in GitHub Discussions, bugs in GitHub Issues, and an IRC channel at #pinta on irc.gnome.org.

Editorial conclusion

Adopt Pinta if you want a Paint.Net-style editor on a GTK desktop and you are willing to run a distribution package or Flatpak rather than build from source. Skip it if your work depends on layers, filters or scripting that the documentation does not describe, or if you need an install path on a distribution whose packages the README never mentions. Before committing, check the CHANGELOG for the 3.1.x line, confirm your GTK and libadwaita versions meet the minimums, and read license-mit.txt alongside license-pdn.txt so you know which files carry which notice.

Frequently asked questions

Official sources

1. License: MIT
2. PintaProject/Pinta on GitHub
3. Project website
4. README
5. Releases