SVG vs PNG for icons: sharpness, size and where each breaks

An SVG stores geometry: paths, fills, a viewBox. The renderer rasterises it at whatever size the moment requires, so a single file is exact at 16, 64 and 1024 px, and on a display you have not bought yet. A PNG stores a grid of pixels at one fixed resolution; every other size is an interpolation of that grid.

That makes SVG the better source. Whatever you hand a generator, the generator has to produce PNGs in the end, and a vector source means every one of them is rendered from the original geometry rather than resampled from somebody else's resize. It is also why the warning about small raster sources matters: a 256 px PNG cannot produce a real 512 px icon, only a bigger blurry one.

File size follows the same logic. A simple mark as SVG is often under a kilobyte and covers every size; the same mark as eleven PNGs is tens of kilobytes. But complexity flips it: a photographic or heavily gradiented logo can be far larger as a vector than as a well-compressed 512 px PNG.

Upscaling cannot add detail. Enlarging a 128 px logo to 512 px gives you soft edges and visible ringing around high-contrast lines, and no amount of sharpening puts back information that was never sampled. This is why generators ask for 1024 px or a vector, and why an honest one warns instead of silently producing a blurry 512.

Downscaling has its own failure mode. Jumping from 1024 px straight to 16 px in a single draw call makes the renderer sample a handful of source pixels and ignore the rest, so thin strokes disappear and edges alias. Scaling down in halving steps, averaging four pixels into one each time, keeps the energy of the whole image and is what a box-filtered chain does.

The practical consequence: generate each size from the largest available source through a proper chain, and never resize one output to make another. Two tools that both produce a 32 px icon can differ visibly, and the difference is the filter, not the artwork.

At 16 px you have 256 pixels to say something with, and roughly half of them are edge. Text is out — a wordmark at that size is a grey bar. Thin outlines are out — a 1.5 px stroke lands between pixels and renders as two half-tone rows. What survives is one bold shape, two colours, high contrast against both a light and a dark tab strip.

Fonts solve this with hinting — instructions that snap stems to the pixel grid at small sizes. Icons have no equivalent: neither PNG nor SVG carries hinting, and browsers do not align your shapes for you. The only hinting available is editorial: simplify the artwork until it reads, then check it at the size it will be used.

A useful discipline is to design the 16 px version as its own drawing rather than as a shrunk logo. Many well-known sites do exactly that: the tab icon is a single letter or glyph from the brand, not the whole mark. You can ship that simplified drawing as the ICO and SVG while keeping the full logo for the 512 px files.

An SVG favicon can contain a style block with a prefers-color-scheme media query, so the same file renders a dark mark on a light tab strip and a light mark on a dark one. It is the only icon format that can react to the browser theme at all, and it costs a handful of bytes.

The catch is coverage: only browsers that use SVG favicons at all will honour it, and your ICO fallback stays whatever colour you baked into it. So design the raster icons to work on both chromes — a mark with its own background, or a shape with enough contrast either way — and treat the media query as a bonus for the browsers that support it.

There is a matching option on the markup side: a media attribute on the link tag, pointing at two different files. Support for it is uneven, so use it as a progressive enhancement rather than as your only plan.

Safari on macOS accepts a mask-icon: a single-colour SVG that it recolours itself, used for pinned tabs and for a few interface accents. Gradients, multiple fills and transparency inside the file are ignored — everything collapses to one silhouette, so a logo that relies on colour to be recognisable will not survive the trip.

Recent Safari versions fall back to the ordinary favicon when no mask-icon is declared, so this is an enhancement rather than a requirement. If you do ship one, flatten the artwork deliberately: convert strokes to filled paths, remove the background, and look at the result as a black shape on white before you trust it.

A raster source cannot produce this file at all. Flattening a PNG gives you a rectangle, because every pixel is opaque; only vector geometry can be reduced to a shape. It is the one output in a modern icon pack that genuinely requires an SVG input.

apple-touch-icon must be a PNG — iOS does not read SVG for home-screen icons. Manifest icons are supported as PNG everywhere that matters; SVG entries are accepted by some browsers but not reliably rendered by Android launchers, so PNG remains the safe answer. The Windows tile is a PNG. And the images inside an ICO are, in practice, PNG streams.

So the realistic answer is both. Use an SVG as your source and as the modern tab icon, and generate PNGs for every platform slot that demands guaranteed pixels. Keeping them in one pack, generated in one pass from one file, is the only way they stay consistent.

One last practical note: keep the SVG you shipped. When the logo changes in six months, regenerating from the original vector takes a minute; reconstructing it from a 512 px PNG takes an afternoon and never quite matches.