Export

Actual size PNG vs big preview

On the tool, pick format PNG then Download for the grid at 1 pixel per cell. Pick Preview to paint each cell as a solid square so you can see it, share it, or trace it. They're the same picture at two scales. Mixing them up is the most common export mistake here.

Look at the meta line before you download. If it says 32×48 px, format PNG yields a 32×48 file. Preview might be 320×480 or thereabouts, because the exporter picks a cell size of at least 8 pixels, aiming near 960 pixels wide. The preview has hard edges. The browser isn't allowed to blur them. If you open it and zoom, you should see squares, not a smear.

When actual size is the one you want

Game engines, app icons, Twitch emotes with a stated pixel size, and any pipeline that will scale the art itself. A 32×32 actual-size PNG dropped into Godot or Unity stays sharp if the importer uses point filtering. If you import Preview instead, you've baked in a scale factor and a possible grid line. The engine then scales that again. You get blur, or double borders.

The sprite converter is aimed at this download. Transparency is real alpha in the actual-size PNG. JPG will flatten it, so don't "save as JPG" in another app afterward if the checkerboard mattered.

When Preview is the one you want

Sharing in a chat, dropping into a slide, printing a reference, or copying cells onto paper. Also when someone asks to "see the pixel art" and a 32-pixel image would render as a dot in the message preview. Check Apply grid if a person will count cells. The lines are drawn on Preview only. They're not part of the actual-size file, and they aren't extra pixels in the grid count. A 32-wide picture with a grid is still 32 art cells.

The copy onto a grid guide assumes this preview. So does a block-build reference. Count the cells in the meta line, not the pixels in the preview file's dimensions.

A failure mode to avoid

Someone downloads Preview, posts it, and later downloads that post (a recompressed JPG) and runs it through the converter again. The new grid tries to pixelate the squares, the grid lines, and the JPEG crumbs. You get a mess that looks "more pixel" and matches nothing. Keep the original photo and the actual-size PNG. Re-export Preview from the tool if you need another size. Moving the width slider rebuilds from the source, which is what you want. Re-uploading an export isn't.

File size is a clue. A 32×32 PNG is often under 2 KB. A Preview of the same art is larger. If your "sprite" is 400 KB, you exported Preview, or you never reduced colors. Sprites at 8 colors and 32×32 are small files. That smallness is useful. It's also a check that you followed the size guide instead of shipping a downscaled photo.

One more split: format Chart, on the stitch and bead pages, is a large image with letters in the cells when the squares are big enough to hold a letter. It's a picture of the chart, not a file another program can edit as pixels. For counting at a desk, print the HTML chart. For a game, ignore Chart and take format PNG from the main converter.

When Preview is mandatory

Use it when someone counts cells on paper or a chat app would shrink a 32-pixel file to invisible. Don't use it as the asset in an engine that expects one pixel per cell.

Export mistake checklist

Meta line copied. Correct format for the pipeline. Grid checkbox state noted (lines never belong in actual-size game files). Original photo kept separately. No re-upload of either PNG back into the tool unless you intentionally want to pixelate pixels. If you're unsure, open actual-size in an editor and count columns manually once. That habit catches most support questions before they start.

Questions

Keep going

• Converter
• Sprite sizes
• Copy the grid by hand
• Sprite converter

Updated 30 September 2026