About this tool
A CSS sprite sheet packs a whole set of small images — icons, UI glyphs, emoji — into one larger image file, then uses CSS background-position to show just the right slice of it for each element. Before HTTP/2's multiplexing, this was a meaningful performance trick: a browser opening a dozen separate connections for a dozen tiny icon files was slower than opening one connection for one combined image, and that gap can still matter on HTTP/1.1 connections, aggressive CDN request-count limits, or generally reducing render-blocking asset requests on a slow network.
This tool builds both halves for you, entirely in your browser: drop in your icon files, choose whether they lay out in a single row or column and how much transparent padding separates them, and it draws them onto one canvas, encodes it as a PNG (to preserve transparency), and generates the exact background-position CSS rule for each one — copy it straight into your stylesheet. That said, sprites are an older technique: for most new projects, inline SVG or an SVG icon font is usually simpler to maintain and scales cleaner at any size, so treat this as one more tool in the kit rather than the only right answer — reach for it when you already have a set of raster icons (PNGs, not vectors) and want to cut down on requests.
Frequently asked questions
Are CSS sprites still relevant, or should I use SVG icons instead?
For most new projects, inline SVG or an SVG icon font/sprite is usually the more modern choice (crisp at any zoom level, easily recolored with CSS, no fixed-pixel-grid alignment issues). CSS sprites remain genuinely useful for photographic/raster icon sets that can't be represented as vector shapes, for legacy codebases already built around the technique, or simply as a fast, dependency-free way to bundle a small icon set with minimal HTTP requests. Use whichever fits your actual constraints — this tool is here for when a raster sprite sheet is the right tool for the job, not a claim that it's always the best choice.
Why is trailing padding not added after the last image?
This keeps the sheet's total size exactly as small as possible — the padding setting exists to prevent texture-bleed BETWEEN adjacent icons when the sheet is scaled/zoomed, which is only a concern for edges shared by two icons; the sheet's own outer edge has no neighboring icon on the other side, so extra space there wouldn't serve that purpose and would just waste file size and add an inconsistency in how far each icon sits from the sheet's absolute edge depending on its position.