Scaling Pixel Art: Check the Sampling Path, Not Just the Export Size

For hard-edged pixel art, start by enlarging the source by an integer factor without smoothing, then inspect the final image in the actual display path. A clean PNG can still look uneven after an engine rescales it, a camera moves between pixels, or a browser displays it at a fractional size.

We are the FrameSprite team and operate tools that include sprite preparation. This guide explains a general test; its examples are calculations, not measurements of a newly produced asset or a guarantee of how your engine will render it.

This article was drafted with AI assistance. Learn about the team on the FrameSprite About page; send corrections through the contact page.

Key points

• Start with an integer enlargement and unsmoothed sampling.
• Check the entire display path, including engine and browser scaling.
• Record the actual source and output dimensions before accepting an export.

Our published sprite-sheet PNG export audit provides related file-level checks before display scaling.

Start with the original grid

Suppose a source image measures 48 × 32 pixels. A 4× enlargement should measure 192 × 128 pixels: each dimension is multiplied by four. Under nearest-neighbor enlargement, one source pixel becomes a block of sampled output pixels rather than being blended with its neighbors. The enlargement preserves the existing grid; it does not invent new artwork or improve a silhouette that was already unclear.

Keep the original small file. Enlarging an already enlarged image again can make it difficult to tell whether a defect came from the source, a prior processing step, or the current display. Compare the original and export at matching proportions before changing the art itself.

Non-integer scaling is different. At 3.5×, a source pixel cannot occupy exactly the same whole number of destination pixels everywhere. Depending on the sampling path and alignment, neighboring columns may appear different widths. That is not automatically a file corruption, but it is a reason to inspect the image at the actual size in which players see it.

Separate file processing from display processing

There are at least three places an image can be scaled:

1. An export tool writes a larger PNG.
2. An engine imports and samples the texture.
3. The game window, browser, operating system, or display scales the final output.

Changing only the first step does not control the other two. The Canvas API's imageSmoothingEnabled property controls whether a canvas context smooths a scaled image. That property applies to that drawing context; it is not a universal setting for every image on the page or every engine renderer.

Similarly, CSS's image-rendering controls a browser's image scaling behavior where supported. Browser implementation and layout still matter. A CSS declaration cannot correct a blurry image that was already interpolated when it was exported.

Make the width difference visible

The diagram below is a teaching example, not a captured export. Each letter represents one source column with a different color. At 4×, four source columns fit into sixteen output columns evenly. At 3.5×, those four columns must fit into fourteen output columns: equal whole-pixel widths are impossible.

Source:       A B C D             4 columns
4x:           AAAABBBBCCCCDDDD   16 columns
3.5x example: AAAABBBCCCCDDD     14 columns
Widths:       4 + 3 + 4 + 3

The last row shows one possible nearest-neighbor allocation. Which colors receive three or four columns depends on alignment and the sampler. The point is the uneven widths, not that every browser must produce that exact sequence. Blended sampling may soften boundaries instead.

To reproduce the comparison without a game project, draw a 4×4 PNG in a pixel editor. Fill each column with a different solid color, with no transparency. Duplicate the original and resize one copy to 16×16 and the other to 14×14 using nearest-neighbor sampling. Open both saved files at 1:1, then count each color's columns with the editor's pixel grid. The 16×16 copy should assign four columns to each source color. Record the actual widths in the 14×14 copy; do not substitute this diagram for an observed result.

If a file has more than the original four colors, inspect whether smoothing, a color conversion, or another processing step was applied. If its file grid is correct but the displayed grid looks uneven, move the investigation to browser, engine or display scaling. Keep the original as the reference for both checks.

Test the same pattern in the display path

Create a small test image with one-pixel vertical and horizontal lines, a diagonal staircase, and a few isolated pixels in contrasting colors. Keep it alongside the actual sprite, rather than using the test pattern as a substitute for reviewing the art.

Compare these cases:

At 4×, a one-pixel source line should become four output pixels wide in the file when the enlargement is an exact nearest-neighbor operation with no other processing. That statement concerns the generated file. It does not establish how many physical screen pixels the line occupies after window or display scaling.

Inspect the diagonal while the sprite and camera move, and record any shimmer or apparent jitter rather than accepting a static screenshot alone. Separate this from asset alignment: the fixed-canvas acceptance test checks whether the source frames themselves shift.

For a specific engine example, Godot 4.4's multiple-resolution guide explains that integer Stretch Scale Mode rounds the scale down to a whole number. This can keep pixel widths even while leaving unused window space. Its pixel-art guidance uses a low-resolution viewport; it also describes a different choice for projects that need subpixel movement. Record the chosen mode and test that configuration rather than transferring one engine's settings to another.

Transparency and color still need their own review

Nearest-neighbor scaling does not repair an existing alpha fringe. Use the light and dark background edge check, including corners and isolated semi-transparent pixels. If a pixel art style intentionally uses semi-transparency, do not delete it merely to make the image look binary.

If the asset is inside a sprite sheet, check that adjacent cells do not bleed at runtime. Padding, extrusion, filtering, and texture-atlas settings interact differently across engines. An enlarged standalone PNG can pass its file check while an atlas import introduces a seam; reproduce the actual packaging and camera setup before declaring the pipeline correct.

Use a tool, then verify its output

FrameSprite's Sprite Sheet Tools include a pixel-art resizing workflow. Select the source, choose the intended factor, download the result, and inspect the actual file dimensions and edges. Availability and limits should be checked on the live tool; this article does not promise a particular output for every input or claim that a new download was tested.

For a handoff, include the original file, exported file, enlargement factor, intended engine filtering, and target viewport assumptions. Record any deliberate deviation such as a fractional UI scale. The final acceptance test is the rendered game at the sizes and motions the project actually uses, not the number printed in the export dialog.

Cover image: AI-generated conceptual illustration, not a screenshot of the product.