Fix AI-Generated Pixel Art Grids with Pixel Snapper Before You Import to Unity or Godot

If you want to fix an AI-generated pixel art grid before the art reaches your engine, the steps are: snap the image to a consistent grid and palette with Pixel Snapper, check the result at 1:1, then import it with settings that match that grid. In Unity that means Point filtering, no compression and matching Pixels Per Unit. In Godot 4 it means Nearest filtering. The sources each cover one of these steps. This guide joins them into one ordered pipeline, based on the project README and the engine documentation.

What goes wrong with AI pixel art, and what Pixel Snapper claims to fix

The Pixel Snapper README says current image models can't understand grid-based pixel art. It names three problems:

• Pixels vary in size and position. One art pixel might cover 7 screen pixels and the next one 9, or sit off the grid.
• Grid resolution drifts across the image.
• Colours aren't tied to a strict palette, so you get many near-duplicate shades.

The tool's stated fix is to snap pixels to a grid, keep the grid resolution consistent and map colours to a quantized palette. The README also says it preserves details such as dithering. These are the maker's claims. The README gives no accuracy figures, comparisons or benchmarks.

The README also suggests other uses: procedural 2D art that doesn't fit a grid, and 2D assets or 3D textures that need to scale cleanly.

Sprite Fusion publishes the project under the MIT license. Sprite Fusion also sells a pixel art generator. The tool is free, but its maker has a commercial interest in AI pixel art workflows.

Choose how to run it: CLI, web or WASM

The README lists several ways to run the tool:

• Online and desktop versions, linked from Sprite Fusion's site (spritefusion.com/pixel-snapper).
• A command-line tool, installed with Homebrew or with Cargo (Cargo needs a Rust toolchain).
• Build from source.
• A WebAssembly build made with wasm-pack, for use inside a web project.

The Homebrew install, as the README gives it:

brew install Hugo-Dz/tap/spritefusion-pixel-snapper

For a game pipeline, the CLI is the most useful option because you can script it. It takes an input path and an output path. The input can be a single PNG or JPEG file, or a whole directory for batch processing. The README says a directory input needs a separate output directory, so don't point both at the same folder.

In practice, batch mode suits loose animation frames or a folder of tiles. If you build browser games and want the cleanup step inside your own tool, the WASM build is the documented route.

Step-by-step: snap a sprite with the CLI

1. Keep the original. Copy the raw AI output to a source/ folder and never overwrite it. Output is always PNG. The README doesn't say the process is lossless on details, so you'll want the original if a snap goes wrong.

2. Run the basic command. The README's form is input, output, then an optional colour count, which defaults to 16:

   spritefusion-pixel-snapper input.png output.png 16
   

3. Let it detect the pixel size first. The README says the tool detects pixel size automatically.

4. Override the pixel size if the result is wrong. The --pixel-size flag sets the size by hand. The README says the value must be between 1 and half the smallest image dimension. Two signs you need an override: the output looks too fine, as if each art pixel was split into several, or too coarse, as if detail was merged away. Set it to the number of screen pixels you think one art pixel covers in the source.

5. Lock the palette for a whole set. The --palette flag takes comma-separated six-digit hex colours. The README's example uses an eight-colour palette, so copy the exact format from there. When you clean a batch of sprites or tiles that must match, pass the same --palette value on every run. If you let each image pick its own 16 colours, related assets can drift apart in hue.

6. Batch the folder. Point the input at a directory and the output at a different one:

   spritefusion-pixel-snapper ./source ./snapped
   

   Add the same pixel-size and palette flags you settled on for single files. The README documents where each flag goes.

7. Inspect at 1:1. The README gives no accuracy figures, so open each output at 100% zoom, or at a whole-number zoom with nearest-neighbour display. Check outlines, eyes, dithered areas and thin details before the file goes near your engine.

Make the numbers agree: pixel size, resolution and Pixels Per Unit

Blurry or shimmering pixel art usually comes from mismatched numbers, not from the art itself. Settle these values before you import.

1. Pick the base resolution first. The GDQuest Godot 4 pixel art guide suggests 16:9 base resolutions such as 320x180, 426x240, 568x320 and 640x360. It suggests choosing one based on your character's height in pixels.

2. Check the snapped sprite against that grid. The pixel size from step 4 tells you how many image pixels make up one art pixel. Divide the cleaned image's dimensions by that pixel size to get its logical size. Say you want a character about 32 art pixels tall on a 320x180 screen. The cleaned sprite should then work out to roughly 32 logical pixels tall. If it works out to 48 or 20, fix that now, not in the engine.

3. Match Pixels Per Unit in Unity. Unity's pixel perfect camera documentation says the camera's Assets Pixels Per Unit must equal the sprites' Pixels Per Unit. It also says Reference Resolution should be your game's pixel art resolution, with 320x180 as its example.

Import into Unity

The Unity 6.3 manual for 2D URP gives these steps for preparing sprites:

1. Select the snapped PNGs and set the same Pixels Per Unit on all of them.
2. Set Filter Mode to Point.
3. Set Compression to None.
4. In the Sprite Editor, set Pivot to Custom and Pivot Unit Mode to Pixels, so pivots land on whole pixels.
5. Add the Pixel Perfect Camera component to the main camera. The manual says it comes with the Universal 2D template. It also says the separate 2D Pixel Perfect package works only with the Built-In Render Pipeline. The package manual describes how the camera handles viewport scaling so art stays crisp at different resolutions.
6. Set the camera's Assets Pixels Per Unit to match your sprites, and set Reference Resolution to your base resolution.
7. For snapping in the Scene view, set Grid Size to 1 divided by Assets Pixels Per Unit. For example, 100 PPU gives 0.01.

If an AI coding agent edits your Unity project, the import settings above are worth writing into its instructions. See connecting Claude Code or Cursor to the Unity Editor and other Unity guides.

Import into Godot 4

According to GDQuest, Godot uses linear filtering by default, which blurs pixel art when it's scaled. The fix:

1. Open Project Settings and turn on Advanced Settings.
2. Go to Rendering > Textures and set Default Texture Filter to Nearest.
3. If a single node needs different behaviour, change its TextureFilter property, which overrides the project default.
4. Set your base resolution and scaling. GDQuest covers viewport scaling and integer scaling, which is the place to look if sprites shimmer or show uneven pixels at non-integer window sizes.

For compression, the sprite-ai.art Godot guide recommends Lossless rather than Lossy in the Import tab for pixel art. sprite-ai.art is a vendor guide, but the advice matches the reasoning in Unity's docs: lossy compression can reintroduce the colour noise the snapping step just removed.

For more engine setup, see Godot guides and the godot-ai MCP server setup.

What are the limits, and who is Pixel Snapper for?

What it doesn't claim. The README describes a fix for grid and palette problems. It doesn't claim to fix bad drawing, anatomy errors, odd perspective or style differences between images. A wonky hand stays wonky. It just lands on a clean grid.

Animation is unverified. The README doesn't say whether batch processing keeps frames aligned across a sequence. Auto-detection runs per image, so two frames could in principle get different pixel sizes or offsets. Setting --pixel-size and --palette explicitly for the whole folder is a sensible precaution. Still, check the frames in sequence, for example in Unity's Sprite Editor or a Godot AnimatedSprite2D preview, before you assume they line up.

No published accuracy data. There are no figures for how often detection gets the pixel size right, so the 1:1 inspection step is required.

Verdict, based on the sources. Pixel Snapper fits solo and indie developers who generate sprites or tilesets with AI and want a free, scriptable cleanup step between generation and import. The CLI, batch mode and palette flag suit asset pipelines. It fits less well if you expect finished, animation-ready art. It handles the grid, not the drawing or the animation. For how AI-made pixel art fits a real project, see the cyberpunk side-scroller specimen. More tools are covered under sprite generators and in Experiments.