Verify a sprite conversion with evidence, not assumptions

A downloaded file is not proof that a conversion is correct. A useful verification process compares the source facts that still exist, the normalized preview, and the final output. This article turns that comparison into a small acceptance test you can repeat before relying on a converted sprite.

Begin with a written source inventory

Before converting, record the source canvas size, expected frame count, frame order, known timing, transparency, and any editor structure you expect to remain editable. For a structured project, also record visible layer names, order, opacity, and whether any cel is smaller than the full canvas or positioned away from (0, 0). This inventory prevents a visually plausible result from hiding a structural loss.

Only record information the source actually contains. A PNG sequence can establish pixels, dimensions, and order supplied by the selected files, but it cannot establish an original layer stack. A GIF can establish decoded rendered frames and timing, but it cannot reveal the editor objects used before the GIF was exported. A project format may contain layers, yet the importer still needs explicit support for their types and properties.

Use a small diagnostic source first

A tiny diagnostic file makes wrong results obvious. Use an asymmetric mark near one edge, at least one transparent pixel, two visibly different frames, and distinct delays when the format supports timing. For a layered source, put a recognizable mark on each raster layer and use different names or opacity values. Avoid confidential artwork; a new synthetic sprite is easier to share if a bug needs investigation.

The compatibility lab publishes deterministic examples for PNG sequence, spritesheet metadata, Piskel, Pixilart, Pixelorama, OpenRaster, Krita, PSD, GIF, and APNG. Those files are useful baselines because the page records the observed dimensions, frame counts, timing, layers, and intentional rejection boundaries.

Check the normalized project before download

The in-page preview reads the same SpriteProject that the exporters consume. Inspect it before creating output:

1. Confirm the canvas width and height match the intended coordinate space.
2. Step through every frame and compare its order and visible pixels.
3. Check each displayed duration, especially where source delays differ.
4. Look at transparent edges and partially occupied cels for unexpected backgrounds or clipping.
5. For supported layered inputs, compare layer names, order, visibility, opacity, and cel placement.
6. Stop if a required property is absent; changing the output format cannot recreate information the importer did not receive.

If the preview is already wrong, downloading again is not a useful test. Return to the source-mode guide, verify that the chosen importer matches the file, and read the exact validation message. The converter rejects many ambiguous structures intentionally rather than guessing.

Open and inspect the exported result

For Aseprite output, open the downloaded file in Aseprite and repeat the inventory check. Confirm document dimensions, timeline length, duration per frame, visible animation, layer stack, cel positions, opacity, and transparency. Toggle supported layers individually. Edit one cel and confirm the change does not unexpectedly affect another frame or layer.

For PNG sequence output, verify the file count and filename order, then compare every flattened frame. For spritesheet output, verify the sheet dimensions, frame rectangles, durations, trimming fields, and JSON-to-PNG pairing. A valid JSON file with the wrong companion image is still the wrong result.

Separate visual equivalence from editability

Two images can look identical while having different editable structure. A flattened frame can reproduce the visible composite but cannot let you hide the original ink layer, rename a source layer, or edit one cel independently. Conversely, a layered result can preserve supported structure while unsupported blend behavior changes the appearance; the conservative importers reject known incompatible cases instead of labeling them preserved.

Use two acceptance statements rather than one vague “looks correct” result:

• Rendered-frame check: the expected visible pixels, transparency, order, and timing match for the tested frames.
• Editable-structure check: the supported source layers, properties, and cel relationships remain separately editable where the source contained them.

Test boundaries as well as success

A trustworthy converter should fail clearly outside its supported subset. Keep the good diagnostic file, then change one condition at a time: make one PNG dimension differ, use an invalid grid size, move an atlas rectangle beyond the image, or introduce an unsupported project layer type in a disposable copy. The expected result is a specific rejection, not a partial download with silently missing data.

Do not corrupt private work to perform this test. Repository fixtures are synthetic and the public lab links to the exact generator and assertions used for maintained compatibility claims. They give you a reproducible boundary without risking an original project.

Record enough detail to reproduce a defect

When a check fails, record the input mode, output format, browser, operating system, Aseprite version, safe error text, canvas dimensions, frame count, layer count, and the first frame where actual behavior differs. Reduce the source to the smallest newly created file that still demonstrates the problem. Never publish private artwork merely to prove that a conversion failed.

Use symptom-based troubleshooting for immediate causes, then consult the matching format guide for its accepted subset. For the meaning of frames, layers, and cels, return to the data-model explanation.