Pixels Per Unit, Explained: Why Your Pixel Art Looks Blurry or the Wrong Size in Unity

If you’ve ever spent your valuable time crafting a beautiful pixel art piece only for it to look like mush once you import it into Unity, the setting to check first is Pixels Per Unit. Not filter mode, not compression (Although, those are very likely culprits as well). This one number decides how big your sprite is in the game world, and getting it wrong is one of the most common reasons pixel art looks off in a Unity project.

I hit this on my own game about a year into building it, when I switched from 16x16 placeholder art to real character sprites and every one of them came in the size of a barn door. The sprites were fine. The number attached to them wasn’t.

What pixels per unit actually means

Pixels Per Unit, usually shortened to PPU, is a setting on every sprite’s Import Settings in Unity. It tells Unity how many pixels of the source image should equal one Unity unit in the game world.

A Unity unit isn’t a real-world measurement like a meter or an inch. It’s just an abstract number Unity uses for positions, physics, and cameras. By convention most Unity tutorials treat 1 unit as roughly “1 meter” for scale purposes, but nothing enforces that. It’s just the number everything else (gravity values, movement speed, camera size) gets tuned around.

So if a sprite is 32 pixels wide and its PPU is set to 32, that sprite is 1 unit wide in the world. If the PPU is set to 16 on that same 32-pixel sprite, it’s now 2 units wide, because Unity is dividing 32 pixels by 16 and getting 2. Same image file, different PPU, different size in the game.

That’s the whole mechanism. PPU is a division: sprite width in pixels divided by PPU equals width in world units. Everything else in this article is really just consequences of that one division.

The problem it solves

Without a rule like this, Unity would have no way to know how big a sprite should be relative to everything else. A 512x512 pixel photo and a 16x16 pixel character sprite are just arrays of pixels to the engine. PPU is what gives them a real size in the world, so a tilemap, a camera, a collider, and a character can all agree on scale.

It also solves a second, more pixel-art-specific problem: keeping art at a consistent, predictable size across a whole project. If every sprite in your game uses the same PPU, then a 16x16 sprite and a 32x32 sprite line up the way you’d expect, a doorway is a door-sized number of units wide, and your tilemap grid matches your character’s feet without any extra scaling on individual objects. Once PPU is consistent, sprite scale stops being something you fix per-object in the Inspector.

How Unity uses the number, step by step

Here’s the chain of math, using Unity 6 as the reference (the behavior is the same back through the Unity 2020+ era, this hasn’t changed).

1. You import an image. Say it’s a 32x32 pixel character sprite.
2. In the sprite’s Import Settings, you set Pixels Per Unit. Say it’s 32.
3. Unity divides: 32 pixels wide / 32 PPU = 1 unit wide. Same for height.
4. When you drag that sprite into the scene, its Transform scale of 1 now represents a sprite that’s 1x1 units in the world.
5. Your camera’s orthographic size (for a 2D camera) determines how many of those units are visible vertically. An orthographic size of 5 shows 10 units of vertical space.
6. Combine those two numbers with your target screen resolution and you get how many actual screen pixels one sprite pixel takes up.

That last step is where blur creeps in, and it’s worth doing the arithmetic once so it stops feeling mysterious. Say your PPU is 32, your orthographic camera size is 5 (so 10 units tall), and your game window is 1080 pixels tall. That’s 1080 screen pixels / 10 units = 108 screen pixels per unit. Divide that by your PPU of 32 and you get 3.375 screen pixels for every 1 sprite pixel. That’s not a whole number, which means some sprite pixels get stretched across 3 screen pixels and some across 4, unevenly, and that unevenness is what shows up as blurry or shimmering edges on pixel art, especially when the camera or a character moves.

The fix isn’t really about PPU on its own, it’s about making that final ratio land on a whole number, like exactly 3 or exactly 4. You do that by matching PPU, camera size, and target resolution on purpose rather than by accident.

Picking a value and sticking to it

There’s no universally correct PPU. What matters more is picking one early and using it for every sprite in the project. The two common approaches:

• Match PPU to your art’s native tile size. If you’re drawing 16x16 tiles, set PPU to 16. A tile then occupies exactly 1 unit, which keeps tilemaps, colliders, and movement math clean (a character moving “one tile” is moving exactly 1 unit).
• Pick a bigger round number like 32 or 64 if your art itself is bigger, or if you want more headroom in the Transform scale before things get fiddly.

What actually breaks projects is mixing PPU values between sprites without meaning to. A 16-pixel prop imported at PPU 100 by default (Unity’s out-of-the-box default is 100, which almost nobody making pixel art actually wants) sitting next to a character imported at PPU 32 will be a completely different size than you expect, and you’ll end up “fixing” it by manually scaling the Transform, which just papers over the real setting and will bite you again the next time you touch that prefab.

The fix: set your PPU once, per project, and apply it to every pixel art sprite on import. You can set a default for new imports in Edit > Project Settings, or in Unity 6 apply a Preset to your sprite import settings so every new asset picks up the same values automatically instead of you retyping them.

If you’re doing tile-based movement or grid layouts, this also has to agree with your tile size and grid cell size. I’ve written through the grid math for tile-by-tile movement in a Unity 2D tilemap separately, and PPU is the setting underneath that whole system: it’s what makes “one grid cell” and “one sprite” actually line up.

The settings people blame instead (filter mode, compression, mip maps)

Before you touch PPU, rule these out, because they cause similar-looking symptoms for completely different reasons:

• Filter Mode. Set to Bilinear (Unity’s default) or Trilinear, this smooths pixel edges as the engine scales the sprite, which is exactly what makes pixel art look blurry rather than crisp. For pixel art, set Filter Mode to Point (no filter) on the sprite’s import settings.
• Compression. Unity may compress sprite textures for smaller build size, which can introduce faint color banding or fuzziness, especially on small palettes. For pixel art, set Compression to None, or at least check it isn’t muddying flat color areas.
• Mip Maps. These generate smaller versions of a texture for use at a distance, mainly a 3D concept. Leaving “Generate Mip Maps” on for a 2D pixel art sprite can cause it to fade or blur when the camera zooms, since Unity is blending between mip levels it didn’t need to build. Turn it off for 2D sprite work.

All three of those live in the same Import Settings panel as PPU, which is exactly why they get blamed together, or blamed for each other. If your sprite is blurry, check filter mode and mip maps first, since fixing PPU won’t fix a blur caused by bilinear filtering.

When pixels per unit is not your problem

PPU controls size and scale, nothing else. If your problem is actually about crispness or wobble rather than size, it’s probably one of these instead:

• Blurry edges at rest, not just in motion: filter mode or compression, covered above.
• Sprites shimmering or jittering while moving: usually a camera or Transform position that isn’t landing on a whole pixel, which is a separate problem from PPU (search terms like “Pixel Perfect Camera” if this is happening, Unity’s 2D package has a component built for exactly this).
• Sprites the wrong size relative to colliders: often the collider was sized before the PPU was finalized, so the numbers don’t match anymore. Reimport or manually resize the collider to match.
• Art looking fine in the Aseprite file but wrong once imported: check the sprite’s Pixels Per Unit against every other sprite in the scene it’s next to, since a single mismatched import is far more common than a systemic camera problem.

Don’t go changing your project’s PPU on a hunch. If one sprite looks wrong, it’s almost always that one sprite’s import settings, not the whole project’s math.

What the same idea is called in Godot and Unreal

If you’ve read tutorials across engines, the same idea shows up under different names, and it’s worth knowing they’re not identical mechanisms.

In Godot 4, the closest equivalent is a project-wide setting, not a per-sprite one: the default is that Godot treats a certain number of pixels as one unit (configurable via project settings and viewport stretch mode), and by default there’s no per-texture PPU field the way Unity has. Godot’s 2D pixel art workflow leans more on the project’s viewport stretch settings and each sprite’s own pixel dimensions than on an editable per-import number.

In Unreal Engine, 2D pixel art isn’t a first-class workflow the way it is in Unity or Godot, since Unreal is built primarily for 3D. Pixel art projects in Unreal typically go through the Paper2D plugin, which has its own texture and sprite scale settings, but it isn’t the same single PPU field Unity exposes.

I haven’t built anything in Godot or Unreal myself, my hands-on experience is with Unity, so treat those two as a starting point for what to search rather than a full walkthrough. The concept (a fixed ratio between source pixels and world units) is shared across all three engines, even where the exact setting isn’t.

A short checklist before you change anything

1. Is Filter Mode set to Point for this sprite? If not, that’s probably your blur, not PPU.
2. Is Compression set to None (or at least checked) on pixel art textures?
3. Are Mip Maps turned off for 2D sprites?
4. Does this sprite’s PPU match every other sprite in the same scene or tileset?
5. Does your camera’s orthographic size, target resolution, and PPU divide out to a whole number of screen pixels per sprite pixel? If not, that’s the source of shimmer on camera movement, not a broken sprite.
6. If you’re using a tilemap, does the tile’s grid cell size match your PPU-derived unit size?

Get those six lined up once, early in the project, and PPU becomes a setting you set and forget rather than one you’re fighting with every time you import a new sprite. If you’re still figuring out which pixel art tool to build that art in to begin with, the pixel art software comparison is a reasonable place to start, and if you want to see PPU and grid math actually applied to a working system rather than just explained, the tile-by-tile movement walkthrough builds on exactly this.