A Developer's Image Asset Workflow

Image assets are the part of a project that quietly rots. Icons get regenerated by whoever is on shift, sprite coordinates drift out of sync with the atlas, inline data URIs get pasted in and never revisited. This is a roundup of the four browser-based tools we use for those jobs and, more usefully, when each one is the right call. If you specifically want icons, start with how to create a favicon.

Icons: one source, several sizes

Browsers and platforms disagree about what a site icon is. You need a small one for the tab, a large one for an Android home screen, and one for iOS. The favicon generator takes a single square image and produces that set as PNGs in a ZIP, along with the link tags to paste into your head.

Output	Used by
16 x 16 PNG	Browser tab and bookmark bar
32 x 32 PNG	Tab on high-density displays, desktop shortcuts
192 x 192 PNG	Android home screen and web app manifest, and the Apple touch icon
512 x 512 PNG	Install prompts and splash screens

A few things worth knowing. Modern browsers all accept PNG favicons, which is why the output is PNG rather than a multi-resolution ICO - true ICO packing in the browser needs a heavyweight library for a format that is now legacy. Start from a source at least 512 pixels square, and design for the 16 pixel case: a logo with fine strokes or a wordmark becomes a grey smear at tab size. Simplify it or use a single glyph instead.

Sprite sheets and texture atlases

Every individual image is a separate fetch on the web and a separate texture bind in a renderer, and both are expensive relative to the pixels involved. Packing many small images into one sheet turns that into a single load and a set of offsets.

The sprite sheet packer takes a batch of images, sorts them by height, packs them into rows against a 1024 pixel target width, and gives you two files: the packed PNG and a JSON map of frame names to their x, y, width, and height. That JSON is the important half - it is what lets an engine or a build step address frames by name instead of by hand-counted coordinates, and it means re-packing after an art change does not require anyone to update a spritesheet CSS file by hand.

Two practical notes: keep source filenames meaningful, because they become the frame keys; and be aware that tightly packed neighbours can bleed into each other under bilinear filtering in a 3D engine, which is the usual argument for adding padding in your art source before packing.

Base64 data URIs, and when inlining actually pays

The Base64 converter goes both ways: image to data URI with a copy button, and a pasted data URI back to a downloadable image. The second direction is the one that saves time most often - decoding a blob you found in a CSS file or an API response to see what it actually is.

For the encoding direction, remember that Base64 inflates the payload by roughly a third, since three bytes become four characters. Inlining is a win when it removes a request that would otherwise block rendering and the asset is small - a handful of interface icons, a tiny background texture, an image embedded in an email template or a single-file HTML document. It is a loss for anything large or reused, because an inlined asset cannot be cached separately, cannot be served from a CDN edge, and gets re-downloaded every time the stylesheet or document containing it changes.

SVG: ship it, but minify it first

Vector files exported from design tools carry a remarkable amount of dead weight - editor namespaces, layer names, comments, and coordinates written to ten decimal places that no display device can resolve. The SVG optimizer strips comments and reduces decimal precision, and the size difference on a typical exported icon is not marginal.

Keep the SVG wherever you can: it stays sharp at every density, it is usually smaller than the PNG of it, and it can be styled with CSS when inlined. Rasterize only when the destination refuses vectors - social previews, some email clients, app store assets. When you do, picking an export scale is the whole decision.

Why client-side matters for this specific job

Developer assets are disproportionately pre-release. The icon set for a product that has not launched, the sprite sheet for an unannounced level, the logo for a rebrand under embargo - these are exactly the files you should not be dropping into an anonymous web service that keeps uploads "to improve the product". Every tool here runs in the page: files are read with the local file API, processed on a canvas or as text, and written back out through a download. Nothing is transmitted, which also means these work offline once the page has loaded and are safe to use on a locked-down corporate network.