Skip to content
AZ Tools

Image Sprite Sheet Generator

Drop several images and bake them into a single PNG sprite — horizontal, vertical or grid — plus ready-to-paste CSS background-position rules.

How to use

  1. Drop or pick the images. They appear in the order the OS hands them over.
  2. Pick layout: horizontal/vertical strips are simplest, grid is denser. Set padding to avoid bleed.
  3. Download the PNG, copy the CSS, ship them together — match the class name you put in the CSS prefix.

About this tool

Show

Combines many small images (icons, UI states, character frames) into one downloadable PNG and emits a CSS block that places each by background-position. Reduces HTTP requests when an icon font, an SVG sprite or an actual sprite-sheet pipeline isn't an option. Layout is horizontal strip, vertical strip, or a fixed-column grid; the sheet is sized to fit the largest item in each row or column. Files are processed entirely client-side via canvas — your icons never leave the browser.

The request-count argument is much weaker than it was. Sprite sheets were a response to HTTP/1.1, where a browser opened about six connections per host and every extra file waited in line. HTTP/2 multiplexes requests over one connection, so fifty small icons cost far less than they used to, and the sheet's own disadvantages start to dominate: one changed icon invalidates the whole cached file, and a page that uses three icons still downloads all fifty.

Where a sheet still wins is the case it was always best at, which is many small images all needed at once. A character animation, a set of UI states that change on hover, or a grid of flags shown together load as one decode rather than fifty, and one PNG compresses better than fifty PNGs because the shared palette and the shared header are paid for once.

The CSS is positional, which makes it brittle in a specific way. Each rule names an offset into a fixed layout, so regenerating the sheet with one icon added or removed shifts every position after it and invalidates every rule below that point. Keep the generated CSS and the generated PNG as one artefact and regenerate both together; editing either by hand is where the two drift apart.

For icons specifically, an inline SVG sprite is usually the better answer today. It scales to any size, inherits currentColor, and can be styled per instance, none of which a raster sheet can do. Reach for this when the images are photographs or pre-rendered frames rather than line art.

Frequently asked questions

Sprite sheets vs. SVG sprites vs. icon fonts?

PNG sprites still win when the source is a real raster (game art, photo thumbnails). For UI iconography prefer SVG sprites (<symbol> + <use>) — they scale and respond to currentColor. Icon fonts are mostly a legacy fallback now.

What happens to transparency?

If you keep the background transparent, the PNG is saved with alpha (the checkerboard you see in the preview is just to make the transparent area visible). If you pick white or black, those are baked into the sheet.

Do sprite sheets still make pages faster?

Much less than they used to. Their point was to avoid the per-request cost of a connection-limited HTTP/1.1 browser; over HTTP/2 and HTTP/3 many small files share one connection and that cost mostly disappears. What a sheet still buys is a single cache entry and one decode, and what it costs is that changing one icon invalidates the whole sheet for every visitor.

The icons look blurry or show a sliver of the neighbour. What went wrong?

Both are the same problem seen twice: a fractional position. If the sheet is scaled, or the element's box lands on a half pixel, the browser samples between cells and you get a soft edge with a hairline of whatever sits next door. Keep positions and sizes to whole pixels at each display density, and leave a couple of transparent pixels between cells so a rounding error has somewhere to land.

Related tools