For context on why and how LibreSprite exists, see [What is the Difference Between Aseprite and LibreSprite?].
Summary: Aseprite is better.
Versions
We'll be comparing LibreSprite version 1.2 (which is a development release) to the latest commit of Aseprite's main branch from Github. Normally I'd rather not compare development releases (i.e. beta, alpha, or release candidates), but LibreSprite 1.1 was released in 2023. There are no patch versions (e.g. 1.1.1). It doesn't feel fair or useful to compare the current Aseprite to a LibreSprite from 2 years ago, so I'm going to assume you'll tolerate using the development version if it means you can use it for free.
LibreSprite seems to have been forked in 2020 given its first release on Github, so there are 5 years of divergence between the two projects. As one would expect, LibreSprite being the volunteer fork has less activity than Aseprite which has paid developers working on it, so in general Aseprite has more features, and that's what this article will be mainly about.
Initial Notes
Upon opening LibreSprite, the GUI scaling is set to 300% by default which means the menus from the menubar literally don't fit my screen. I think this is why they put Edit -> Preferences at the top of the Edit menu instead of at the bottom.
Aseprite seems to be at 200% by default for me, so I didn't have this problem with it.
Features that Aseprite has that LibreSprite doesn't have
Methods for Expression
These are the most important differences: features that can't have workarounds that enable unique workflows, or with very impractical workarounds.
Aseprite has tablet support: including both pen pressure sensitivity for size and opacity of brushes and stabilizer functionality. The changelog of LibreSprite claims to have initial support as well which works automatically, as opposed to being something you can enable and configure like on Aseprite, but I haven't been able to confirm it.
Aseprite can skew: after selecting pixels or adding text, LibreSprite can only rotate and scale, while Aseprite can also skew.
Aseprite has a gradient tool: LibreSprite only has a bucket fill tool.
Aseprite can fill inside dithered pixels with bucket fill: while the bucket fill tool is selected, there is a "pixel connectivity" setting that will let the bucket fill cross pixels diagonally to fill areas that otherwise would be considered separate.
Aseprite has a normal map color wheel in addition to RGB and RYB. This kind of raises the question: why? Who is editing normal maps for 3D models using a pixel art editor? Is this a thing these days? Is it Minecraft's fault? Well, anyway, it supports it.
Asesprite has non-square pixel aspect ratio. When you create a new document, you have the choice to use 2:1 and 1:2 aspect ratios instead of 1:1. I have absolutely no idea why would anyone want this, but it's possible.
Aseprite has tilemap layers: it can automatically display a list of tiles you have created on a sprite by storing it as a tileset, and then use those tileset in a different layer to place layers. To be honest, I'm bit confused about how to use it, but I suspect it's extremely useful for pixel artists who work with tiles.
For Pixel Art Animation
Aseprite has more animation playback options: you can play the animation in the preview window without playing it in the main window, allowing you to edit a single frame while the animation plays. It's also possible to play at different speeds, such as 0.25x, 0.5, 2x, and 3x.
Aseprite can bring a layer to front/back per frame: each cel has a z-index property that can be changed to change the order of the layers on a frame basis, allowing you to create complex animations where one layer just goes above the other for a while.
Aseprite can repeat sections of the animation: you can tag a range of frames with a tag and set that tag's property to repeat a number of times. When you play the animation, those frames will repeat without you having to manually copy and paste them.
Basic Usability
Basic functionality that you would expect from this type of software.
Aseprite can hide the interface: Aseprite has an "advanced mode" that hides the user interface similar to the same feature on drawing software such as Krita and Clip Studio Paint. This can be done by pressing Ctrl+F (the menubar will be hidden, so the only way to leave it is by pressing Ctrl+F again). This is useful since the menubar, toolbar, tab bar, and statusbar consume a lot of vertical space leaving less for the main pane.
Aseprite has groups (folders) for layers: you're reading this right, despite having 4 years to add the ability to layer groups to LibreSprite, it's still not there, and my personal philosophy toward open source software not having a feature right now, no matter how simple it looks, is that you should just assume it's never going to happen (e.g. GIMP taking 7 years to add multiple layer selection). To be fair, mtPaint and Grafx2 also lack this feature, so I guess it's only Aseprite and GraphicsGale that have it.
Aseprite has scrollbars for menus that are too tall: LibreSprite simply won't let you click on the items at the bottom if they don't fit the window.
Advanced usability
Aseprite uses no dialog for editing colors: in earlier versions of Aseprite and on LibreSprite, to edit a palette color you click on a pencil button that displays a dialog for it. This is a bit awkward since there already is a color picker on the sidebar, but clicking on its just changes which palette color is currently selected by choosing the color on the palette that most closely approximates the color you picked. Aseprite has since changed how it works from a dialog to a modality: the pencil button became a padlock, and when the padlock is unlocked picking a color on the sidebar changes the color of the selected color in the palette without requiring a floating dialog for this task. This unified how selecting color works, since you no longer have two separate interfaces for the same action.
Observation: having tried LibreSprite previously, I hadn't noticed it had support for alpha transparency even in the indexed palette color modes because you have to open the color editor to see that. On Aseprite there is an opacity slider visible on the sidebar, so the feature is more easily discoverable.
Observation: mtPaint's color dialog is ridiculously unusable (e.g. it lets you edit both foreground and background color simultaneously, but if they are both set to the same palette index, then when you save it the background values will overwrite the foreground even though only the foreground values are displayed by default). Meanwhile, GraphicsGale's with the color picker just under the palette feels very intuitive. I feel like there is a pattern here, so if you make your own pixel art editor one day, avoid adding a dialog to it just to edit the palette color!
Aseprite has reference layers: you can put an image file inside your sprite to trace over it if you want. Reference layers can't be edited except for moving them and are listed with a crossed name. It seems they don't extend beyond the canvas' boundaries like in Krita. If you need something more complex like a mood board, I recommend BeeRef.
Aseprite has a slice tool: you can specify rectangles for parts of a single file to export. It seems you can only export the slices through the terminal, no dialog for this, which is a bit of a disappointment. It also has a 9-slice option for creating slices for buttons, borders, etc. that are resizable but have unique corners. Changing the properties on the property dialog of the slice doesn't automatically display the changes until you click OK, which is also unfortunate, but I assume this proves itself very useful when designing 9-slice graphics even if it's the only thing you have in a file since it shows guidelines.
Asesprite can intersect selection: LibreSprite can only add or subtract to the existing selection.
Aseprite has a button to save the palette as preset: presumably this is also possible on LibreSprite if you manually save the palette in the palette folder, but on Aseprite it's an item in the menu.
Aseprite can use real dialog windows: by default, dialogs like the dialog to insert text are simply rendered inside the main window so they can't be dragged off the window. There is a setting in preferences to change this behavior. Changing this setting also allows menus to extend beyond the window.
Aseprite has an outline FX: you can quickly add outlines to sprites and text with it, and it has several options to configure out the outline pixels are added.
Aseprite has more color adjustments: brightness and hue/saturation. LibreSprite only has color curve.
Aseprite has more preferences: one area where the improvements are very easy to measure is the amount of settings in the preferences dialog that Aseprite has compared to LibreSprite. While I don't feel the need to change anything, every additional setting is probably something someone wanted to customize the behavior of that was added to the application.
Minor interface improvements:
A button to display the timeline on the toolbox' bottom right corner, on LibreSprite it's not obvious you have to press Tab.
The resolution of the file is always displayed on the statusbar, on LibreSprite you must hover the main pane.
Can paste as a new image, as a new layer, or as a reference image through the Paste Special submenu.
Shared Features
Horizontal and vertical symmetry modes: this is noted in LibreSprite's 1.0 change log, but seeing as it works identically to Aseprite it might have been a feature that was finished in Aseprite already when the fork was done but hadn't been published yet.
Features that Libresprite has that Aseprite doesn't have
I'm struggling to find any, to be honest.
I'm checking the change log because this feels like a game of Where is Waldo, but I can't find anything other than bug fixes and technical improvements. No actual features.
I thought "Scripts" was an unique feature because it was on the menubar, but Aseprite has it as well in the File menu. I can't really tell what more "scripting support" means. People want to draw pixels. Not write scripts.
It says "better text tool" from 2021, but I can't seem much difference from Aseprite's in 2025, and Aseprite can do skewing, which LibreSprite can't. One thing I noticed while double clicking to select the font is that LibreSprite appears to use a custom double click speed ignoring your operating system, which is set to too fast for me so it felt like double clicking didn't do anything. Aseprite seems to have fixed that or it simply uses a slower constant speed.
Wait, I think the touchbar is LibreSprite-only. This is an extra bar on the left eight large buttons for common operations like undo, redo, add layer, and add frame.
Features that neither LibreSprite nor Aseprite have
Neither application seems to provide a quick way to draw dithering. Both GraphicsGale and mtPaint have dithering options that make every pixel you draw dithered with a brush. You just select the pattern, no need to draw it. On LibreSprite and Aseprite, you have to draw the dithering first, then select create brush to create a brush from the dithering you drew and then you can use it to draw the dithering. Additionally, you can't change the brush size for some reason. On GraphicsGale and mtPaint, you can have any brush size with any dithered texture, but on Aseprite when a textured brush is selected you can't change its size. It was a cool thing I found in GraphicsGale when I first tried it that most software seem to simply not have. On the other hand, to be completely fair, GraphicsGale only has 3 brush sizes, you can't make it arbitrarily large like in Aseprite.
Additional Observations
I'm not sure, but it seems Aseprite has a better support for extensions while LibreSprite is limited to scripting. Although third-party plugins can help a lot no matter the format, they aren't part of the main software so they won't be included in this review.
Abandonware?
In 2022, LibreSprite posted that they would be completely rewriting the project. If you are a programmer you probably know what the punchline is going to be.
The ones following the development might have noticed how our GitHub went silent in these weeks (Months by now). But that's not totally true, as we kept working behind the curtains👷
Since we were facing too many problems with LibreSprite code structure, we opted for a completely rewrite of it (yes, we're that crazy) as it would take us less than cleaning the current code as we go. And changed the name, since it's a complete rewrite.
So, tadaa, shake it a bit, add a good dose of @FManga, and you obtain LibreSprite Dotto! Yes, LibreSprite Dotto! is a work in progress, but it already supports things like scripting, multiple windows management, skins/themes, and so on. Not bad if you ask me
https://libresprite.github.io/#!/news (accessed 2025-04-15)
I don't enjoy criticizing free labor, but on the list of things anyone wants on a pixel art editor, scripting and skins are probably not even on the list, so I'm not sure I understand these priorities.
As one would expect, Dotto is abandonware now, with features like "Copy + Paste" still in "Planned" status 2 years later.
I'm trying very hard to not rant about this for 3 paragraphs, but they actually chose to use SDL for the rewrite instead of a GUI toolkit like Qt or GTK. They actually went there, and said: "I can't understand any of this code, let's rewrite it from scratch in a way nobody else can understand it."
How many times people said "Aseprite looks cool but the GUI looks bad, they should rewrite it to use a proper GUI" and the one guy who rewrites it chose not to do that!
I shouldn't laugh at this, but it's too funny. It's alright, FManga, starting side projects you can't finish is programmers' national sport. Nobody can blame you for giving up writing an entire application while you're writing an entire GUI toolkit for free. I'd give up as well.
The point is: I wouldn't expect LibreSprite to get any significant updates in the future. The software is as-is, don't count on it getting better. If it works for you, great. If it doesn't, find something else. Despite there still being activity on the repository, the amount of activity it receives is minuscule compared to what Aseprite gets.
- https://github.com/LibreSprite/LibreSprite/graphs/contributors
- https://github.com/aseprite/aseprite/graphs/contributors
Comparing these two graphs you can see that the main contributor of LibreSprite is the author of Aseprite, dacap, with 4473 commits. On Aseprite, full repository, dacap has 8400 commits. Despite the efforts of FManga (felipemanga), there is simply nobody that is working or has ever worked on LibreSprite as much as Aseprite's main contributor. It's not even close. There has been a few contributors that sent one or two commits over the years, but for the most part the source code has been simply left untouched.
Conclusions
Based on the observed features, we can conclude that Aseprite provides a large number of additional features compared to LibreSprite, specially advanced features that help professional workflows like reference layers, repeating sections of animations, dithering-aware bucket fill, pen pressure support, etc.
Critically, I don't think there are many reasons to use LibreSprite instead of GraphicsGale if you're just drawing some pixel art, since both are free, and both run on Linux (although you'll need WINE). The main differences would be symmetry support and semi-transparent pixels. Aseprite, on the other hand, adds features like reference images, tilemaps, slices, and a lot of animation support, so no matter what you're trying to do, Aseprite will have a feature to help you with it.
One interesting conclusion from this comparison is what it means to open source projects. In the past, there have been cases of open source applications that changed licensed terms or direction leading to a fork carried by different developers, e.g. LibreOffice. For a long time I believe that the community backslash could be enough for the fork to happen, but Aseprite shows a different story. When most of the code is written by a single developer, it simply can't survive or fork in reality without that one person contributing more code to it. They can change the license terms without having to worry about the existing source code competing against their new non-open-source project, because nobody is going to add features to it or add patches when users can simply buy the new versions of application from the original developer.