Fit an Image to Pixel Art Grid (Tile-Ready)

Fitting a source image to a pixel art grid is a different job than making an image “look pixelated.” A game engine cares about one thing: does every pixel of the exported sprite land exactly on a tile cell so the tilemap does not shear at the seams? Get the grid wrong and every scene shows a one-pixel jitter that no filter later can hide. Get it right and the same PNG is drop-in for Phaser, Godot, Unity, or an HTML canvas game with zero engine-side surgery.

What image to pixel art grid actually means for tiles

Type “image to pixel art grid” into a search engine and two very different reader groups show up. The first wants a decorative pixelated Instagram filter — mosaic-style, no engine involvement, print it on a mug. The second is a game developer who needs a source image to land on an integer pixel grid so a tilemap or sprite atlas can import it without seams. This howto is written for the second reader.

The distinction matters because a “pixelated” filter can round pixels any way it likes and still look artsy. A tile-ready pixel art conversion has three non-negotiables:

• A locked target resolution the artist picks up front — 16×16, 24×24, 32×32, 48×48, or 64×64 are the common tile sizes for indie games.
• A bounded color palette so the sprite reads as authored art instead of a random JPEG downsample.
• A hard alpha edge when the subject is a character or item — no anti-aliased halo bleeding into neighboring tiles.

Sorceress ships two tools that together handle this pipeline in the browser without any Photoshop-scale software: BG Remover for the alpha plate and True Pixel for the grid quantization. The rest of this howto walks the four ordered steps — plate, cut, quantize, export — and explains what each dial does under the hood, so a mistake in step one does not force a redo of step four.

Pick a tile size before you upload

The single biggest reason a converted image ends up mis-aligned to a tilemap is that the artist skipped the “pick the target grid” step and let the tool guess. Do not let the tool guess. Pick the tile size from the game camera, not from the source photo, and set it once for the whole scene.

Concrete rules for a jam-scope project:

1. Top-down retro (SNES-style dungeon crawler, Legend-of-Zelda-alike): 16×16 for terrain tiles, 16×16 or 24×24 for heroes and enemies. The camera is close and the reader expects a chunky look.
2. Side-scrolling platformer: 32×32 for terrain, 32×32 to 48×48 for the hero. Big enough that walk cycles read clearly, small enough that a scene fits on the screen at native zoom.
3. Portrait / UI card art: 64×64 or 96×96. This is not a world tile — it is a fixed panel — so the grid can be bigger without breaking scene continuity.
4. Boss or full-body character screen: up to 128×128, single-sprite only. Do not use this for a walkable world.

Open True Pixel and check the header — a small emerald Grid2X2 icon and a live {targetWidth}×{targetHeight} readout appear once a source is loaded. The default is targetWidth = 64 and targetHeight = 64 (both declared in src/app/pixel-art/page.tsx, verified July 31, 2026). Override both to your chosen tile size before you touch the palette. If you are converting several sprites into the same scene, use the Profiles menu to save the target and palette together so every subsequent sprite lands on the same grid.

Two rules never worth breaking:

• The target grid is a property of the scene, not of the source photo. A 4-megapixel phone photo and a hand-drawn 500-pixel concept both quantize down to the same 32×32 cell if that is your world grid.
• Once locked, never change the target mid-atlas. Change it and every earlier sprite is a different size than the new one — the atlas will not align in-engine.

Cut the background if the plate is messy

Two source types show up in the “image to pixel art grid” queue and each takes a different path.

1. Seamless tile or texture: a photo of grass, a stone wall, a wooden floor, a metal sheet, a concept illustration meant to tile in a tilemap. Skip BG Remover entirely and load the source directly into True Pixel. No transparency needed — the whole rectangle is the tile.
2. Character, enemy, item, or prop: a hero photo, an object cutout, an NPC portrait. The subject must land on a transparent background so the sprite can composite over any tilemap. Route through BG Remover first, then hand the transparent PNG to True Pixel.

For the second case, the numbers to remember are hard-coded in the page source. BG_REMOVER_CREDITS is set to 3 and MAX_FILE_SIZE_MB is set to 5 in src/app/bg-remover/page.tsx (verified July 31, 2026). A batch of ten character plates is 30 credits, which is roughly $0.30 at the standard 100-credits-per-dollar rate. Anything over 5 MB is skipped with a warning banner, so downscale phone photos to about 2,048 pixels on the long side before you queue the run.

Under the hood the page posts to Replicate with model: "bria/remove-background", which resolves to Bria RMBG 2.0. That model returns 256-level alpha, not a binary cutout, which is generous with hair and fringe but occasionally too soft for pixel-art work. That is fine — the next tool in the pipeline handles the hard-edge pass, so BG Remover only needs to isolate the subject.

One nuance: if the sprite is going to sit on a black or very dark tilemap and RMBG returns a visible halo, the halo will show. Preview every cutout on a magenta-and-gray checkerboard before quantizing. If the halo is loud, re-shoot the source or crop tighter before spending nine credits on three retries — as covered in the related background remover AI howto.

Convert on True Pixel with the grid preview on

With a target size chosen and (optionally) a clean alpha plate, load the source into True Pixel and open the palette panel. This is where the grid actually happens. The tool runs three coordinated operations under one Generate button: a downscale from source resolution to the target grid (using true nearest-neighbor sampling, not bicubic), a color quantization to a chosen palette, and an optional corridor-key alpha pass that hardens the edge.

Eight palette presets ship in the tool, declared at PALETTE_PRESETS in src/app/pixel-art/page.tsx (verified July 31, 2026):

• PICO-8 (16 colors) — the safest first pick for fantasy platformers. Warm, saturated, forgiving.
• SWEETIE-16 — 16 colors tuned for readability on modern LCDs. Slightly cooler than PICO-8.
• Endesga 32 — 32 colors, natural skin tones and mineral shades. The pick for painterly characters.
• Game Boy (4 colors) — 4 shades of green. Retro handheld look, no exceptions.
• CGA (16 colors) — pure IBM 1981. Choose for a hard old-PC aesthetic.
• NES (54 colors) — the full NES master palette. Historically accurate, though most scenes use a 25-color subset.
• Grayscale (8 colors) — for HUD icons or pre-color line work.
• 1-Bit (2 colors) — pure black and white. Silhouette study, UI glyphs.

The palette assignment uses a perceptual color-distance function (weighted Euclidean in sRGB with extra weight on the green channel), which matches how the human eye reads brightness — the details are in colorDistance at the top of the same file. In practice the choice means a red pixel in the source will pick the nearest red-family palette entry instead of the nearest total-RGB neighbor, which keeps material color coherent across a subject. This is the theory behind color quantization — reducing an image’s palette while preserving perceived structure.

Turn on the grid preview so the tile cells are visible while you tune. The corridor-key alpha pass — the paid step that hardens the sprite edge — costs getCkCreditCost(frameCount, w, h) credits: 1 credit per image up to 512 pixels on the long side, 2 credits above that, multiplied by ceil(frameCount / 10) for video mode (line 2414 of src/app/pixel-art/page.tsx, verified July 31, 2026). Set the corridor backend to local for zero-credit iteration on a single sprite; that runs the entire alpha pass in your browser.

Align the grid to engine tilemap coordinates

A sprite quantized at 32×32 does not automatically land at cell (0, 0) of a tilemap. It lands wherever your engine’s tilemap loader tells it to land — which is why the export step is not “download PNG and forget.” Two engine-side habits keep the grid honest.

Habit one: tell the engine to sample with nearest-neighbor. Bilinear or bicubic filtering blurs a pixel-art sprite the second the camera does anything but 1× zoom. In Phaser, load textures with Phaser.Textures.FilterMode.NEAREST; the concept is documented in Phaser’s texture pipeline. In a plain HTML canvas game, set the CSS image-rendering: pixelated property on the canvas element. In Godot, set the project’s Rendering > Textures > Default Texture Filter to Nearest. All three route to the same underlying algorithm — nearest-neighbor interpolation, which is the mathematically correct choice for a pixel grid.

Habit two: match the tilemap origin to the sprite origin. True Pixel exports at native resolution — a 32×32 sprite is a 32×32 file, not a 512×512 upscale of a 32×32 image. If your engine treats sprite origin as top-left, tile cell (0, 0) is exactly the top-left corner of the exported PNG. If the origin is center (Godot’s default), account for the 16-pixel offset in placement code. Do not “fix” this by baking a padded transparent border into the export — that pushes every downstream cell alignment off by whatever padding you added.

The general principle here is old — pixel art as a discipline has always been about deliberate pixel placement. The engine settings above just tell the runtime to respect the placement decisions you already made at conversion time.

Export PNG-8 vs indexed sprite sheets

Once the grid preview passes, export at native resolution as a lossless PNG. Two formats are worth knowing about:

• PNG-24 with alpha — the default. Full 24-bit color plus an 8-bit alpha channel. Bigger file, no palette metadata. Ships fine to every engine.
• PNG-8 indexed — 8-bit indexed color (up to 256 palette entries) plus 1-bit or 8-bit alpha. Smaller file, palette embedded. Some retro-focused engines detect indexed-color PNGs and skip their own color-quantization step, which preserves the exact palette you chose.

For a jam-scope project the file-size difference between PNG-24 and PNG-8 is negligible on modern connections, so PNG-24 is safe. For a shipped mobile game or a project where every kilobyte of the .apk matters, PNG-8 is a real optimization. Both formats are compatible with any 2D engine — the choice is about disk size and palette-preservation intent, not compatibility.

For sprite sheets, export each animation row at the same target grid, then stitch them together in an atlas tool. Sorceress ships a Quick Sprites flow that automates the animation-row side of this handoff and honors the exact same target grid you used in True Pixel, so a locked 32×32 hero stays 32×32 across walk, idle, and attack sheets.

One warning: some image converters offer a “bake the upscale into the export” toggle that ships a 4× or 8× enlarged PNG as the final file. Never take it. A pre-upscaled export triples file size for zero visual gain (the engine can upscale at draw time), and it locks the engine into a specific zoom level. Ship the native-resolution PNG and let the engine handle nearest-neighbor at whatever zoom the camera decides.

When the grid pass fails a color budget

Not every source photo converts cleanly to a locked palette. Three failure modes come up regularly, each with a specific fix that beats “try a different tool”:

1. The subject color drifts across the grid. A hero’s red cape reads as three different reds across the 32×32 cell because the source photo had a gradient. Fix: switch to a smaller palette (Game Boy 4 or PICO-8 16) so the quantizer collapses similar hues into a single palette index. Or hand-recolor the source at 128×128 first before running the grid pass.
2. Details vanish at the target size. A sword or wand disappears entirely at 16×16 because the detail is smaller than a source pixel after the downscale. Fix: increase the target size (32×32 or 48×48) or hand-paint the detail back in on top of the quantized output — pixel art is authored, not just extracted.
3. The palette clashes with the tilemap. The hero looks fine alone but jars against a Game Boy tilemap because the character was quantized on PICO-8. Fix: pick one palette for the entire scene and re-quantize every asset against it. Palette mixing across sprites in the same scene is what makes a converted game look “AI-produced” instead of “designed.”

Two stop rules keep the loop honest:

• Do not run five palette variants “to compare.” Pick one from the scene lock and commit. Compare quantized-vs-source, not quantized-vs-quantized.
• If a subject still fails after two attempts at the target size, the fix is in the source photo (lighting, crop) or in the choice of subject (some references simply do not read as pixel art at 32×32). Escalate to the broader Sorceress tools guide for adjacent workflows — a hand-drawn canvas approach is sometimes the honest fix.

The core loop for the image to pixel art grid pipeline is short: pick the tile size from the scene, cut the plate in BG Remover if the subject needs alpha, quantize in True Pixel at the locked target with a chosen palette, export native-resolution PNG, and let the engine upscale with nearest-neighbor. Two sibling workflows are worth stacking beside this one — the browser pixel art playbook for hand-authored assets, and the image-to-pixel-art sprite pipeline for the animation-row side. All three route back to the same principle: the grid is a property of the game, not the photo, and every dial in the tool exists to respect that.