PixiEditor 2.x: three toolsets and a node graph over one canvas
PixiEditor is a Universal Editor for all your 2D needs
At a glance
- What is it?
- The editor that distinguishes PixiEditor from a dedicated pixel art tool is that pixel art, painting and vector share one canvas and one node graph. The cost is that the release notes are dominated by rendering and scaling fixes.
- Who is it for?
- PixiEditor is the right choice when one asset has to move between pixel art, painted and vector treatment, or when a procedural shader node should sit in the same document as hand-drawn pixels, because that mixture is the product rather than a feature checkbox.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 7, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Three toolsets, deliberately not separated
Version 2.0 reorganized PixiEditor around three toolsets that ship by default. Pixel art holds the tools for pixel-perfect work, painting holds basic brushes, soft brushes and anti aliased shapes, and vector holds shapes and paths. The claim that matters is the next one: all three can be used on one canvas, and you can mix vector with raster.
That is the whole argument for the editor. A sprite that starts as pixel art and later needs a smooth gradient or a bezier path does not need a round trip through another application, and an export of png, jpg, svg, gif or mp4 comes out of the same document.
The repository is C# with Avalonia in its topic list, which is how one binary reaches Windows, Linux and macOS rather than three codebases. The root tree carries `src/`, `tests/`, `samples/`, `assets/` and an `incompatible.json`, the last presumably tracking document or feature compatibility across versions. There is also a `Third Party Licenses/` directory with a `gen_third_party_licenses.sh` script, which matters more than usual for an LGPL-3.0 project that links against a large set of libraries.
The node graph is the layer everything else sits on
PixiEditor describes its node render system as the thing that makes the rest possible: all layers, effects and the layer structure are nodes, or a result of the connections between them. Every document exposes its node graph, and the README frames that as freedom to customize an image and to make procedural art and animations.
This is where the difference from Aseprite becomes concrete. Aseprite is a sprite editor whose primitives are pixels, frames and layers. PixiEditor's document has a graph you can insert custom shader nodes into, and the release history confirms the graph is load bearing rather than decorative: version 2.1.2.2 includes a change to the shader node default code, moving it to version 300, plus a merge branch named graph-color-fixes, and 2.1.2.3 lists a fix for a separate and color node with HSV and HSL.
So the trade is real in both directions. If your work is hand-authored pixel art, a node graph is a layer of concept you did not ask for. If you want a gradient or a hue rotation to be a graph node you can rewire, the same architecture is the reason the editor exists.
Animation is present, vector keyframes are on the roadmap
Version 2.0 added a timeline and animation capability. You can build animations frame by frame, and the README also says you can use nodes to animate custom shaders. What it does not claim is vector keyframes: key frame animations with vectors are listed as being on the roadmap.
The 2.1.2.x releases have been tightening animation rather than extending it. Version 2.1.2.2 contains fixes for Pixel Perfect tools in the Animation Editor and for animation previews, and removes a small memory leak. Version 2.1.2.3 then changed the autosave behaviour so it is explicitly enabled for opened documents rather than automatic, which is the kind of change that reads as a response to users losing or finding unexpected saved state.
The screenshots referenced for the timeline are from the 2.0 announcement. If you are deciding on the basis of the animation feature set, read the recent release notes first rather than the README, because the release notes are where the actual behaviour is being corrected.
Three patch releases in a month, mostly about rendering
The recent history is dense and unusually specific, which makes it the most useful document in the repository. Version 2.1.2.2 on 2026-08-23, 2.1.2.3 on 2026-09-02, and 2.1.2.4 on 2026-09-04.
What the fixes have in common is rendering fidelity rather than features. Version 2.1.2.3 lists wrong rendering scaling in some cases, a high dpi preview fix, anti aliasing for shapes in pixel art, selection bounds when resizing documents, font caching, null checks in font operations, and a missing icon. Version 2.1.2.4 carries a single change: an invalid render scaling issue, which reads as a follow-up to the scaling work rather than an unrelated defect.
For a user that means display scaling is where bugs have been landing, on high DPI displays and on documents whose size changes. For a reader evaluating the project it means the 2.1.2.x line is actively stabilised rather than abandoned, with the repository not archived and the last push on 2026-09-21.
The README's badges still point at the previous organization
The repository lives at PixiEditor/PixiEditor, and the merge commits inside the release notes agree, naming pull requests from PixiEditor. The README's own badges do not. The release badge links to github.com/flabbet/PixiEditor/releases, and the downloads badge points at github.com/flabbet/PixiEditor/releases/total. The auto-generated release summaries at the bottom of each release body link to a dev.azure.com project under the flabbet organization.
Both sets of references were presumably correct at some point, and the Azure DevOps link explains the pattern of a project that moved hosting as well as ownership. But a reader following the README's release badge does not land on the release list for the code they are reading.
The reliable paths are the ones the repository itself states: the releases of PixiEditor/PixiEditor, the homepage at pixieditor.net, the download page at pixieditor.net/download, and the compile guide and start-here pages under pixieditor.net/docs/contribution. Note that the README carries no build commands of its own; compiling from source means following the external compile guide.
Where the documentation stops
The README is short, which is appropriate for a project this size and means most of what you want is elsewhere. It establishes the three toolsets, the shared canvas, the export formats, the node graph, the timeline, and the fact that vector keyframes are pending. Everything operational lives on pixieditor.net: the download page, the compile guide, a contribution start-here page, a help section, a forum at forum.pixieditor.net and a Discord server.
The repository carries the usual governance files, a `CONTRIBUTING.md`, a `CODE_OF_CONDUCT.md`, a `PULL_REQUEST_TEMPLATE.md`, and an `assemblyVerReader.ps1` PowerShell script that suggests version numbers are assembled from several sources during the build.
There is also a discrepancy worth naming because it shapes expectations. Search interest around this project includes extension-related phrases, but the README documents no extension API and the tree shows no extension directory, so the plugins people ask about are not documented at the repository level. The README also links a Steam store page, so the editor is distributed through Steam as well as its own site. On licensing, GitHub reports LGPL-3.0 and a LICENSE file is present, with the third party notices directory alongside it; check both when you plan to redistribute a build.
Editorial conclusion
PixiEditor is the right choice when one asset has to move between pixel art, painted and vector treatment, or when a procedural shader node should sit in the same document as hand-drawn pixels, because that mixture is the product rather than a feature checkbox. It is a weaker choice for pure pixel art work where Aseprite's workflow is the reference, and the release history is a warning there: rendering scale, high DPI preview and pixel art anti aliasing fixes occupy 2.1.2.3 and 2.1.2.4. Build from source only if you have Avalonia and .NET set up, otherwise take the download, and note that the README's release and download badges still point at the old flabbet organization.
Frequently asked questions
How does PixiEditor compare with Aseprite?
Aseprite centres on pixels, layers and frames as its primitives. PixiEditor puts all layers, effects and structure into a node graph exposed on every document, which is what lets custom shader nodes, vector shapes and pixel art coexist on one canvas. That extra model is a benefit for procedural work and overhead for pure sprite work.
What export formats does PixiEditor support?
The README lists png, jpg, svg, gif and mp4 from the same document, which works because vector and raster content share one canvas rather than living in separate files.
Can PixiEditor animate vector graphics with keyframes yet?
Not yet. Frame by frame animation and node driven shader animation are supported in 2.0, and the README lists key frame animations with vectors as on the roadmap. Recent releases such as 2.1.2.2 and 2.1.2.3 fix existing animation behaviour rather than adding vector keyframes.
Is PixiEditor free and open source?
GitHub reports LGPL-3.0 and the repository contains a LICENSE file, so the source is open. The README links a download page on pixieditor.net and a Steam store page, and the repository ships a Third Party Licenses directory with a script to regenerate it, which is what you would check before redistributing a build.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/pixieditor-pixieditor)