A pixel art upscaler that keeps every pixel a perfect square

Because a fractional scale cannot give every original pixel the same size. At 2.5x some source pixels have to become two output pixels wide and their neighbors three, and which ones get which falls wherever the rounding lands rather than anywhere an artist chose. Across a flat area nobody notices. Along a diagonal or a one-pixel outline it shows up as a stagger that alternates thick and thin, and that stagger was not in the artwork. A whole multiple has no such decision to make: at 3x every pixel is three across and three down, everywhere. Type a width into the field and the page will name the two whole multiples that sit around it.

Almost certainly not, and this is the commonest mistake in the whole operation. Pixel art circulates at display size rather than at working size, so a 32 by 32 sprite reaches you as a 512 by 512 PNG in which every original pixel is already a 16 px block. Enlarging that by four gives you 64 px blocks in a 2,048 px file — larger, and not one pixel sharper. This page measures the block size before it does anything else and works from the artwork underneath, so the same file at 8x comes out as 256 px of genuine 32 by 32 art.

Yes — set the multiplier to 1x. The page has already collapsed the file onto its native grid in order to measure it, so 1x simply exports that: a 640 by 640 PNG carrying 20 px blocks comes back as the 32 by 32 image somebody scaled up before they posted it. This works because pixel-art editors enlarge by whole numbers, which is what makes the enlargement reversible. A file that was resized to a percentage has had its block edges averaged into each other and there is no original left in it to recover.

It is the opposite operation. A neural upscaler invents detail that was not in the file, which is its entire purpose and genuinely useful on a photograph or a scan. On a sprite it produces a smooth painting of a sprite: an artist placed each of the 1,024 pixels in a 32 by 32 piece deliberately, and a model asked for 4x has to invent the other 15,360 — that is painting over the work rather than enlarging it. Nothing is added here. The output holds the colors the input held, in the arrangement the input had, at a larger size — which is why the color list below an enlargement is identical to the color list above it.

Because those algorithms change the artwork, and this page exists for the cases where it must not be changed. They are very good at what they were written for, which is smoothing an emulator's output on a modern screen, and they do it by reading each pixel's neighbors and rounding staircases into diagonals. That introduces colors the palette never held and moves edges the artist placed. If the enlargement is going to become beads, bricks or stitches, a rounded corner is a unit you cannot buy; if it is going back into a game, the sprite no longer matches the rest of its sheet.

Your file has been through a lossy encoder, in practice always JPEG. JPEG stores 8 by 8 tiles as frequency coefficients and rebuilds hard edges with an overshoot, so a block that left the editor as one flat color comes back with a gradient across it and a halo at its border. The number reported beside the block size is the widest channel drift found inside any single block: 0 means the file is untouched, and anything past roughly 20 out of 255 means the colors listed underneath have been reconstructed rather than read. Each block is still averaged back to one color, which is the best answer available, but the result is a repair.

Yes, and it stays transparent rather than turning white. Any block whose mean alpha falls below half is treated as a hole and written into the PNG with an alpha of zero, so a sprite cut out against nothing comes back cut out against nothing. This is worth checking on whatever tool you use, because a great many online resizers composite onto a white background before they scale — which leaves a white fringe one block deep around every edge of the artwork for you to key out afterwards.