Aseprite Shading Tool Not Working | Fix Common Glitches

If you fire up Aseprite, switch to the shading ink, and the brush refuses to shade or darken, it can stall an entire sprite. You tweak colors, restart the app, and still nothing seems to happen on the canvas. This guide walks through why the shading ink behaves in this way and how to get it back to a predictable state.

The shading ink is not a normal brush mode. It expects a base color from a selected gradient, works differently on tilemaps, and reacts to the current ink type, layer, and even the mouse button you press. Once you understand those rules, the aseprite shading tool not working problem turns into a short clear checklist instead of a guessing game.

Why The Aseprite Shading Tool Feels Broken

The first shock with shading ink is that it does not draw new pixels on an empty layer. It only moves colors along a gradient that you define in the palette for that specific sprite file. If the pixels under your cursor do not belong to that gradient, nothing happens and it looks like a bug.

Another surprise is that left and right mouse buttons move colors in opposite directions across that gradient. Left usually pushes toward one end of the ramp, right moves toward the other. If you expect both to behave like a regular brush, the tool feels random and unreliable.

On top of that, shading ink respects layer type, transparency, selections, and lock settings. A locked alpha channel, a hidden selection, or an incompatible tilemap layer can all make strokes vanish. In many cases the engine is working exactly as described in the official shading and ink documentation, but the setup on screen does not match those expectations.

How The Shading Ink Works In Aseprite

Before you fix anything, it helps to see how shading ink is supposed to behave in a clean file. This runthrough mirrors the official shading documentation and gives you a baseline that you can compare with a broken file.

1. Draw A Base Shape — Paint a simple blob or cluster with a single palette color on a normal layer using simple ink.
2. Select A Gradient Range — In the palette, drag over several colors that include the base color plus lighter and darker steps. This range becomes the ramp for shading.
3. Switch To Shading Ink — In the context bar, change the ink from Simple to Shading so the brush starts moving colors instead of laying down new ones.
4. Shade With Left Click — Paint over the base shape with left click to nudge each pixel toward one side of the gradient, often the darker end.
5. Shade With Right Click — Use right click to push pixels toward the other side of the ramp, often the lighter end.

In indexed color mode, shading moves through palette entries, so the exact order of colors in the palette matters a lot. In RGB mode the range still comes from the selected colors, yet the effect feels closer to a brush that blends between the sampled colors. If your sprite uses one mode and your test file uses another, the same gradient can behave in noticeably different ways.

When this setup works in a test file, you know the core shading feature behaves as expected. If the same steps fail in your actual project, a setting, asset type, or tool state must differ. That is where the most common shading issues show up during normal work on sprites and tiles.

Common Causes Of Aseprite Shading Tool Not Working

Most shading problems fall into a few repeatable patterns. The table links each symptom to a cause and a correction.

Quick Shading Troubleshooting Table

Symptom	Likely Cause	Quick Fix
Brush does nothing on a filled area	Pixels are not in the selected gradient range	Select a ramp that includes the base color and nearby steps
Shading works only on certain colors	Gradient range is too narrow or uses a different palette row	Expand the range in the palette so it reaches every shade in the sprite
Tool refuses to draw new shapes	Shading ink only changes existing pixels that match the gradient	Switch to Simple ink to sketch, then return to Shading for light and shadow
Nothing happens on a tilemap layer	Tilemap settings or tile content do not match the gradient range	Test shading on a normal layer, then adjust the tilemap content and palette
Shading only lightens or only darkens	Wrong mouse button or reversed shade setting	Try the other mouse button and toggle the reverse option in the shading controls
Shading works in one file but not another	Different palette, color mode, or layer lock state	Copy the working layer setup into the problem file and match those settings

These issues show why the tool feels temperamental. It does not guess which colors you want to treat as a ramp. It simply moves pixels along the specific gradient you have selected and only if those pixels already belong to that set.

• Check The Gradient First — Confirm that the base color and its steps sit inside the selected range in the palette bar.
• Confirm The Layer Type — Try shading on a flat raster layer with no locks before you work inside tilemaps or special layers.
• Look For Hidden Selections — Clear any active selection that might clip the stroke to a tiny area of the canvas.
• Turn Off Lock Alpha — If alpha lock is on, shading may ignore transparent pixels that should stay editable.

Step-By-Step Fixes When The Shading Tool Stops

When you run into aseprite shading tool not working in a real project, it helps to move through a repeatable checklist. Each step removes one source of confusion and puts the file back in a simple, testable state.

1. Test On A New Sprite — Create a small new file, draw a base color patch, set a gradient, and try shading ink there first.
2. Reset To Simple Ink — Swap back to simple ink, confirm that normal painting works, then set ink to Shading again.
3. Match The Palette — Compare the palette rows between your broken file and the test file so gradients line up with actual sprite colors.
4. Disable Special Modes — Turn off blend modes, masks, tilemap specific options, and pixel perfect mode while you debug.
5. Check Mouse Buttons — Press left and right on the same area to see which side of the gradient each button uses.
6. Watch The Status Bar — Keep an eye on any message that hints at a locked layer, hidden selection, or tool limit.

If shading works in the test file but still fails inside your main project, compare basic properties side by side. Check sprite size, color mode, palette rows in use, tilemap layers, and blend modes. Many stubborn problems turn out to be a mismatch between those basics instead of a hidden bug.

Once shading behaves on the test sprite, copy those working settings into your main project. That may mean moving the sprite into a new file, importing the working palette, or recreating layers with simpler states before you reapply tilemaps and effects.

Shading Problems With Custom Brushes And Tilemaps

Many artists bump into shading bugs only when custom brushes or tilemaps enter the scene. In clean files the ink behaves well, then a custom brush that used to work with simple ink starts to ignore half the gradient.

Recent reports mention shading ink that lightens but refuses to darken when a custom brush is active. The core shading logic still respects the gradient and mouse buttons, yet the custom brush parameters limit how color changes apply across the patterned stamp. This can feel like a regression in recent builds, but the root lies in how the brush saves ink settings and shade data.

The brush parameter panel includes toggles for ink type, opacity, pattern color, and an extra switch that preserves the shade gradient. If the brush saved an old combination of those values, it may fight the current ink mode. Refreshing the brush while shading ink is active ensures that its stored parameters match the behavior you expect.

Custom Brush Fix Checklist

• Recreate The Brush — Build a fresh custom brush while shading ink is already active so the saved parameters match your current setup.
• Check Brush Parameters — Open the brush parameter menu and confirm that ink type, opacity, and shade extras are stored as expected.
• Test With Type Brushes — Switch back to the round or square type brush and try the same gradient to see whether the issue is brush specific.
• Compare With A Normal Layer — Paste a copy of the tile or stamp into a standard layer and shade there to see whether the tilemap or brush is at fault.

If the problem only appears with a particular custom brush and build, you might be hitting a bug that others have already reported. In that case the best workaround is to shade with standard brushes or simpler pattern brushes, then reapply more complex custom stamps afterward until an update lands.

Workflow Tips To Keep Shading Reliable

Once you have shading back, a few habits make it much less likely to fail during a session. These habits keep gradients tidy and reduce surprises when you switch between flat painting and shading passes.

• Save Palette Ramps — Organize palette rows as light to dark ramps so you can grab full ranges with a single drag.
• Bind Ink Shortcuts — In the shortcut settings, assign quick actions that flip between simple ink and shading ink while you hold them.
• Use Separate Shading Layers — Place shading strokes on their own layer above the base colors so you can test and revert effects quickly.
• Keep A Test Sprite Nearby — Maintain a small tile or blob next to your main sprite that you use only for fast shading tests.
• Document Your Setup — Write down palette rows, gradient ranges, and ink choices inside a note layer or project text file.

Another useful habit is to keep version notes with your sprite files. You can open an older file, compare the metadata, and see whether a program change or a palette swap matches the moment when the behavior changed.

Over time this builds a rhythm: sketch with simple ink, switch to shading for light and shadow, and always keep one clean sample area where you can confirm that the feature still behaves as expected. With that rhythm in place, shading problems stop being a mystery phrase and turn into a quick checklist you can clear in a few minutes.