Six Aseprite Features I Ignored for Two Years, and Now Use on Every Sprite

I’ve been drawing sprites for my JRPG, Crown Code Chronicles, for a while now, and for a good chunk of that time I was using Aseprite like it was another MS Paint with a grid. It took way too long before I sat down and found out what the software could do, instead of just what I was used to doing in it. Here are six game-changing (literally and figuratively) features that changed how I work, roughly in the order I wish I’d found them.

These notes refer to Aseprite 1.3.x, which has been the current stable version for a while. If you’re on an older version some of the menu names might be in slightly different spots, but the features themselves have been around for a long time.

I drew sprites the slow way for two years

For a long time my process for a new character was: draw frame one on a blank canvas, duplicate the frame, nudge some pixels, repeat. No tags, no layer groups, no onion skinning, nothing. Every animation was one long strip of frames in a single file, and every export was a manual guess at how Unity would slice it.

It worked, as in sprites got made. It also meant every animation took longer than it needed to, every file got harder to read the longer I worked in it, and I re-solved the same export problem from scratch every single time. None of these six features are obscure. They’re all sitting in menus I’d scrolled past a hundred times. I just hadn’t stopped to ask what they were for.

Tags, so one file holds every animation

A tag in Aseprite marks a range of frames and gives it a name, a color, and a playback direction (forward, reverse, or ping-pong). Right-click above the timeline, choose “New Tag,” drag it across the frames that belong to that animation, and name it. Idle, Walk, Attack, Hurt, all living in the same .aseprite file instead of six separate ones.

The payoff isn’t just tidiness. Once your walk cycle and attack animation are both tags in one file, you can scrub between them instantly to check that a character’s proportions and color palette match across animations — an easy consistency error to miss when each animation is its own file in its own window. It also means one export can hand you a sprite sheet with clean, named sections instead of a pile of loose PNGs you have to remember the order of.

Layer groups and why my character files stopped being unreadable

A character with separate layers for base body, outfit, weapon, hair, and a couple of shading passes gets out of hand fast, especially once you’re multiplying that across several animations in the same file. Aseprite lets you group layers into folders in the Layers panel: select the layers, right-click, “Group Layers.” You can collapse a group down to one row, rename it, and toggle its visibility as a unit.

I group by parts (Base, Outfit, Weapon, Hair) rather than by animation, since the parts stay the same across animations but the poses don’t. It’s a small change, but scrolling past 4 rows instead of 20 every time you need a shading layer makes the file much less of a chore to work in.

Onion skinning settings I had switched off by default

Onion skinning shows a faded version of the frame before and after the one you’re on, so you can see where a limb was and where it’s going without flipping back and forth.

The onion skin settings (the small dropdown next to the onion skin toggle in the timeline) let you control how many frames show before and after, how much they fade, and whether it loops around the animation instead of stopping at the first and last frame. Turning the opacity down and limiting it to one frame before and after gave me a faint, useful guide instead of a smear. For a walk cycle especially, this is the fastest way to keep footfall spacing and arm swing consistent frame to frame instead of eyeballing it against a static reference frame.

Custom palettes, and loading Lospec palettes straight into Aseprite

I pick palettes from Lospec for most of my sprite work, and for a long time I was manually eyedropping colors out of a reference image instead of loading the palette properly. Aseprite reads palette files directly: from the Palette menu, choose “Load Palette” (or drag the .gpl or .png palette file straight onto the Aseprite window), and every color from that palette shows up in your swatches.

Loading the palette gives you the swatches, but note that in RGB color mode Aseprite still lets you pick any color you want — the palette doesn’t hard-lock the picker. If you want the palette actually enforced, so a stray off-palette color can’t sneak into a sprite, switch the sprite to Indexed color mode (Sprite > Color Mode > Indexed), where the image can only use colors from the loaded palette. Lospec’s palette list exports in formats Aseprite reads natively, so there’s no manual color-matching step at all.

Sprite sheet export settings that match how Unity slices them

File > Export Sprite Sheet is where I lost the most time early on, mostly because I didn’t understand what Unity was going to do with the file on the other end. A few settings that matter for a Unity import:

• Sheet type: “By Rows” or “By Columns” with a fixed frame size per cell. Unity’s automatic sprite slicing works off a grid, so a sheet with uneven cell sizes will slice wrong no matter how you set it up on the Unity side.
• Trim: leave this off for anything you’re slicing on a grid in Unity. Trim tightens each frame’s bounding box to its non-transparent pixels, which shrinks and shifts frames by different amounts and destroys the fixed cell size you need for grid slicing.
• Padding / border padding: a couple of pixels of padding around each frame stops bleeding between adjacent sprites when Unity’s texture filtering samples slightly outside a cell’s edges, which shows up as a faint line of the neighboring frame’s color at the edges of your sprite.
• Data file: exporting the JSON data alongside the sheet (Array or Hash format) gives you exact frame coordinates and tag names, worth having if you ever want to script the import instead of manually slicing sprites by eye in Unity’s sprite editor.

If you’re still getting inconsistent sizing or blurriness once the sheet is in Unity, that’s usually a Pixels Per Unit and import settings problem rather than an Aseprite one. I wrote up how that setting works in Pixels Per Unit, Explained.

Reference layers for lining art up with the tile grid

A reference layer displays in the canvas but never exports and can’t be drawn on directly, meant for things like a locked background image you’re tracing over or matching proportions to. Right-click a layer and check “Reference Layer,” then lower its opacity so it sits behind your actual art without getting in the way.

I use this for lining up character sprites against a screenshot of my tile grid, so a character’s feet land where they should relative to a tile’s edges instead of me guessing at the offset and fixing it later in Unity. If you’re working with grid-based movement, getting that alignment right in Aseprite saves you from discovering a two-pixel offset after you’ve already wired up animation states. I went through exactly that building tile-by-tile movement, which I wrote about in Grid-Based Movement in Unity 6.

What I still do badly

I don’t use Aseprite’s scripting or CLI batch export at all, which means every time I add a new animation I re-export by hand instead of running one command that regenerates every sheet in the project. I also still eyeball frame timing rather than setting individual frame durations properly, so some of my animations play slightly too fast or slow and I only notice once they’re in Unity next to other animations at a different pace. Both are on the list. Neither has been painful enough yet to force the fix, which is probably how the other six sat ignored for two years.

One thing to try on your next sprite

If you only take one thing from this, make it tags. Take whatever multi-frame animation you’re working on right now, even if it’s just sitting as a loose strip of frames, and turn it into a named tag. It costs about thirty seconds, and it’s the one change that makes every other feature here easier to use — once your animations have names, everything from onion skinning to exporting starts organizing itself around them instead of around frame numbers you have to remember.

If you’re still deciding whether Aseprite is the right tool for your project at all, I put together a comparison against a few of the alternatives in Best Pixel Art Software for Game Dev, covering what each one is actually good at rather than just a feature checklist.