Sprite Animation Previewer

A sprite sheet tells you nothing about timing, and timing is most of what makes an animation work. Frames that look fine side by side can read as a stutter at 12 fps and as mush at 24. The only way to know is to watch it.

Three problems show up immediately in playback and almost never in a static sheet. A loop seam: the last frame is too close to the first, so the cycle hitches once per revolution. A registration error: one frame is drawn a pixel off-centre, and the sprite twitches every time it comes round. And uneven spacing: two frames doing the work of one, so the motion accelerates halfway through.

Stepping frame by frame with the arrow buttons is the fastest way to find the second one. Narrowing the range to two or three frames and letting it loop is the fastest way to find the other two.

In Aseprite, File → Export Sprite Sheet with JSON Data ticked on the Output tab. Drop the PNG and the .json in together and three things change.

The frames come from the file, not from a grid you worked out or a detection pass that had to guess. Different frame sizes, irregular spacing and trimmed exports stop mattering.

Timing is per frame. This is the part a single frame-rate slider cannot express. A walk cycle usually holds the two contact frames — where the foot lands and takes the weight — longer than the passing frames between them, and animators do that on purpose. Played at a flat 12 fps the whole thing reads as mechanical. Each frame's hold is shown under its thumbnail in the timeline, so you can see which ones were given the extra time.

Tags become an animation picker. Selecting one sets the range and the direction together, so a ping-pong tag plays as a ping-pong and a reverse tag plays backwards without you finding the loop control. Nothing has to be counted out of a sheet holding idle, walk, attack and hurt end to end.

The GIF export uses the same timings, so what downloads matches what you watched. One caveat the format imposes: GIF stores delays in hundredths of a second, so a 100ms Aseprite frame is exact while 33ms is written as 30 — a rounding you will not see, but which is there.

TexturePacker JSON works too. It carries the frame rectangles but no durations or tags, so you get the accurate cut and keep the frame-rate slider.

Most hand-drawn pixel animation lives between 8 and 15 fps. That is not a technical limit — it is a drawing budget. Every frame is a frame somebody has to draw, and beyond about 15 the extra ones stop adding readable information and start adding work.

Fast actions are the exception: an attack or a dash often runs at 20 to 24 fps for the few frames it lasts, because the motion is meant to feel abrupt. Idles go the other way, sometimes as low as 4 to 6 fps.

Whatever you choose, note it down — the engine needs the same number. A cycle authored at 12 fps and played at 10 in Godot will look subtly wrong and you will blame the art.

The GIF is encoded here, in the page, with no upload and no service in between. Two properties of the format are worth knowing before you rely on it.

Timing is quantised to 10ms. GIF stores each frame's delay in hundredths of a second, so 10 fps (10cs) and 20 fps (5cs) come out exact, while 12 fps rounds to 8cs — 12.5 fps in a player. The tool shows the rounded rate. The format also cannot go faster than 50 fps, and many viewers silently floor anything under 2cs.

Transparency is one bit. A pixel is either fully transparent or fully opaque; there is no partial alpha. Pixel art almost never uses partial alpha, so this rarely matters — but a sprite with a soft glow or an anti-aliased edge will show a hard boundary in the GIF that the PNG did not have.

The palette holds 255 colours plus transparency. Pixel art usually uses a few dozen and comes through exactly; anything with gradients gets quantised down.