# Krita: what the KDE painting application actually ships, and where it stops

> Krita is a GPL-3.0 digital painting application built on KDE and Qt, aimed at illustrators, comic artists and texture painters. The repository is a KDE mirror on GitHub, the build path is long, and the README's AI moratorium is the most concrete policy signal in it.

**KDE/krita** — Krita is a free and open source cross-platform application that offers an end-to-end solution for creating digital art files from scratch built on the KDE and Qt frameworks.

- Repository: https://github.com/KDE/krita
- Website: https://invent.kde.org/graphics/krita
- Stars: 10,435 · Forks: 865
- Language: C++
- License: GPL-3.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/kde-krita

## The problem Krita solves, and who the README says it is for

The README opens with a positioning statement rather than a feature list: Krita is for artists who want to create professional work from start to end, and it names comic book artists, illustrators, concept artists, matte and texture painters, and the digital VFX industry. That is a narrower audience than "everyone who draws on a computer". The application is a raster painting tool built on KDE and Qt, distributed under GPL-3.0, with individual files allowed to carry a different but compatible license. If your work is vector logos, page layout or photo retouching for print, the README gives you no reason to switch. If your work is a long illustration session with layered brushes and a canvas that has to stay responsive, that is the stated target. The licence matters here for a practical reason: GPL-3.0 means you can read, modify and redistribute the source, and the README points to the KDE-hosted repository for exactly that. The GitHub copy is described as a mirror, so issues and merge requests belong on KDE infrastructure, not on GitHub.

## How the codebase is put together, from the top-level layout

The repository root tells you most of what you need to know before you open a single source file. CMakeLists.txt at the top level and a cmake/ directory mean the build is CMake-driven, and the many config-*.h.cmake files are generated headers that switch optional features on or off at configure time: config-ocio.h.cmake for OpenColorIO, config-mlt.h.cmake for the MLT framework, config-mypaint.h.cmake for MyPaint brush support, config-tiff.h.cmake and config-jpeg.h.cmake for image formats, config-hdr.h.cmake for high dynamic range handling. That pattern is the architecture in miniature: Krita is assembled from optional dependencies, and what your build can do depends on what your system provides. The krita/ directory holds the application proper, while 3rdparty/, 3rdparty_plugins/ and 3rdparty_vendor/ hold bundled dependencies and plugins. Tooling is unusually explicit for a project of this size: .clang-format and .clang-tidy define code style and static analysis, .git-blame-ignore-revs keeps formatting commits out of blame output, and .gitlab-ci.yml plus .kde-ci.yml describe the continuous integration that produces the binaries the README links. There is also a benchmarks/ directory and a dev-tools/ directory, which is a signal that performance work is treated as a first-class concern rather than an afterthought.

## Installing Krita from a nightly build and starting a first canvas

The README does not give a package-manager command for end users. It points to the project website at krita.org and to the user manual at docs.krita.org for that, and it gives the nightly build locations instead. Unstable builds live under the KDE CI CDN at the master path, and stable builds under the krita-5.2 path. If you want to try an unreleased build on Linux, the README's developer-build route is to open Krita's CI jobs page, find the latest linux-debug-weekly job, and download the AppImage from that job's artifacts. The same page lists a linux-asan-weekly job for builds compiled with AddressSanitizer in both Qt and Krita. The README notes that ASAN needs environment variables set before the AppImage will run usefully.

```bash
export ASAN_OPTIONS=new_delete_type_mismatch=0:detect_leaks=0
```

After exporting that variable, you run the AppImage from the directory where you downloaded it. The README does not document a first-run wizard or a default canvas size, so the first canvas is whatever you configure in the application itself.

## Windows ASAN builds and why the working directory matters

The Windows path is more fiddly, and the README is explicit about why. You find the latest windows-asan-weekly job, browse its artifacts, and download the .zip. After extracting it, you set the same ASAN options in a Windows terminal, then change into the bin directory of the extracted folder before launching the binary. The README states the reason plainly: if you run from elsewhere, ASAN cannot locate llvm-symbolizer.exe and the backtraces it produces will not contain proper symbols. That is a real constraint, not a stylistic preference, and it is the kind of detail that decides whether a crash report is useful to the developers.

```bash
set ASAN_OPTIONS=new_delete_type_mismatch=0:detect_leaks=0
cd c:\path\where\you\downloaded\krita-5.3.0-prealpha-git12345\bin
krita.com
```

## Building from source is a documented detour, not a quick start

The README does not embed build instructions. It sends you to the online documentation page for building Krita, and to a separate page listing developer guides and notes. That is a deliberate choice: the build depends on the optional libraries named in the config headers, so a generic set of commands would be wrong on most machines. Practically, this means the entry cost for contributing code is higher than for a single-language project. You need a working KDE and Qt development setup before CMake will configure, and the feature flags in cmake/ decide whether OpenColorIO, MLT, MyPaint brushes, TIFF and JPEG support are compiled in. If you only want to paint, ignore this section entirely and use a nightly or distribution build. If you want to change brush engines or the colour pipeline, budget time for dependency resolution before you touch krita/.

## The AI moratorium is the sharpest constraint in the README

Most project READMEs avoid policy. This one does not. The README states that because the developer community cannot currently find consensus on whether AI tools may assist development, a moratorium is in place until October 2026, and that until a decision is made, the use of AI when working on Krita is not allowed. Three reasons are given: anticipated backlash from users and supporters, the absence of a KDE-wide policy that a Krita policy might conflict with, and uncertainty about how AI development itself will change. Whatever you think of the policy, its practical effect is unambiguous for contributors. If you submit a patch, you are asserting it was not produced with those tools. This is the single most consequential line in the document for anyone planning to send code upstream, and it sits alongside a feature freeze table showing that on master, features and strings are both currently allowed.

## Where Krita is the wrong tool, and what to compare it against

The README's own scope statement is the best guide to Krita's limits. It describes a digital painting application, not a general graphics suite, so tasks outside painting are not its job. Two concrete gaps are visible in the repository itself. First, platform reach: the README links a separate README.android.md, which implies Android is handled as a distinct, separately documented target rather than a first-class desktop equivalent, and the README says nothing at all about iOS or iPadOS. If your workflow depends on an iPad, Krita's own documentation gives you nothing to evaluate. Second, the AI question: the moratorium means the project is explicitly not pursuing AI-assisted features through its contributor base right now, so anyone looking for generative inpainting built by the community will not find it here. Compare that with a proprietary subscription tool such as Photoshop, where the vendor ships generative features on its own schedule and you have no vote. Krita inverts the trade: you get the source and the licence, and you accept that features arrive when volunteer contributors and KDE's release process allow. For comic and texture work the README's audience statement suggests the trade is worth it; for a team that needs a vendor SLA, it is not.

## Maintenance, upgrades and what the licence means in practice

The repository is not archived, and the README's freeze table shows master currently accepting both features and strings, which indicates an open development branch rather than a frozen one. The README does not give a last-commit date, and no such date is available here, so treat any claim about release cadence as unverified and check the commit history on the KDE repository yourself. Upgrades follow the two nightly tracks the README names: unstable under master and stable under krita-5.2, with the caveat that nightly builds are not covered by the CI status table. On licensing, Krita as a whole is GPL-3.0, and the README notes that individual files may carry a different but compatible licence. That combination is normal for a KDE project and means redistribution carries source obligations; it does not restrict your ownership of the artwork you create, though the README does not address output licensing and you should not read a statement into its silence. If you fork, the LICENSES/ directory and the COPYING files at the root are the authoritative texts to read rather than this summary.

## Conclusion

Adopt Krita if you paint raster artwork, comics or textures and you want a GPL-3.0 application whose source is hosted by KDE rather than a proprietary subscription. Do not adopt it expecting a mature Android or iPad release, or a scripting surface that the README documents in detail; the README points to Android notes in README.android.md and says nothing about iOS. Before you commit, verify three things: which nightly branch you are pulling from (master or krita-5.2), whether your distribution package matches the version you intend to paint in, and that the mirror you are reading on GitHub is not the real repository, which is invent.kde.org/graphics/krita.git. If you plan to contribute, read the AI moratorium first: the README states the use of AI tools when working on Krita is not allowed until October 2026.

## FAQ

### Is Krita actually free?

Yes. The README describes Krita as a free and open source digital painting application, and states that Krita as a whole is licensed under the GNU Public License, Version 3, with individual files possibly under a different but compatible licence.

### What are the disadvantages of using Krita?

The README scopes Krita to digital painting for artists, so it does not present itself as a general graphics suite. It also links separate Android notes and says nothing about iPad or iOS, and its AI moratorium means AI-assisted development is not allowed until October 2026.

### How do I install Krita?

The README does not give a package-manager command; it points to krita.org and the user manual for that. It does list nightly builds: unstable under the master CDN path and stable under the krita-5.2 path, plus AppImage artifacts from the linux-debug-weekly and linux-asan-weekly CI jobs.

### Which is better, Procreate or Krita?

The README does not compare Krita with Procreate, so no judgement can be drawn from it. What it does state is that Krita is cross-platform, GPL-3.0, and built on KDE and Qt, with no mention of iPad or iOS support.

### Is Krita just as good as Photoshop?

The README makes no comparison with Photoshop. It describes Krita as an end-to-end solution for creating digital art from scratch, aimed at comic artists, illustrators, concept artists, matte and texture painters, and the digital VFX industry.

### How do I use Krita animation?

The README does not cover animation workflows; it points to the user manual at docs.krita.org for feature documentation. The repository itself only tells you how to build, run and report bugs against Krita.

## Sources

- [Official documentation](https://invent.kde.org/graphics/krita)
- [Official README](https://github.com/KDE/krita#readme)
- [Project repository](https://github.com/KDE/krita)

---

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