Convert SVG to AVIF

AVIF is the most efficient still-image format in general use and it is worth the migration for photographs, screenshots and product shots. None of that reasoning transfers to a drawing. An SVG is a description of shapes, so it is already about as small as the picture can be expressed, and it renders at whatever size the layout gives it without a second file.

The measurement: a 140-byte test drawing rendered at the default 1,024 pixels came out as a 9,730-byte AVIF. Real logos are larger as SVGs — a few kilobytes is typical — but the conclusion holds at that scale too, and the AVIF is the one that also needs a srcset and a fallback. If the reason for this conversion was byte count, it is working against you.

There are four, and they are worth knowing because they are not obvious. The first is an SVG that is not really a vector: a file produced by tracing a photograph, or one with a base64 raster embedded inside it, both of which can run to hundreds of kilobytes and will encode far smaller as AVIF. The second is a drawing that leans on filters — Gaussian blurs, blend modes, complex clipping — which browsers implement with real differences, so rasterising once makes the result identical everywhere.

The third is a pipeline constraint: a CDN transform, an image proxy or a CMS that handles raster formats and refuses SVG. The fourth is trust — an SVG is XML that can carry script and external references, so a site accepting drawings from users often rasterises them rather than maintaining a sanitiser. Any of those makes this conversion correct. "Everything else is AVIF now" does not.

The property being given up is easy to underrate. A single SVG serves a phone at 3× density, a laptop at 2×, an external monitor at 1× and a print stylesheet, all from the same bytes, and it is sharp on every one. The moment it becomes an AVIF it serves exactly one of those well.

Recovering the rest means rendering at several widths and writing a srcset, which is three or four files and a chunk of markup where there was one file and none. That complexity is the real cost of this conversion, and it is larger than the kilobytes on either side of the comparison.

The scale setting is the only decision the conversion asks you for. The default renders 1,024 pixels wide and the height follows the drawing’s own proportions; the range is 0.1 to 10, giving 102 to 10,240 pixels.

The habit worth having is to find the largest CSS width the image will ever occupy and render at twice it, which covers 2× displays without going to a full srcset. A logo shown at 180 pixels wants a 360-pixel render, not a 1,024-pixel one — and at those dimensions the AVIF is genuinely small, which does not change the fact that the SVG was smaller and served every density at once.

AVIF is the intra-frame path of a video codec, built to predict blocks from their neighbours and discard the residual detail a moving eye will not catch. On a photograph that residual is texture. On a drawing it is the edge of a letterform, and the default quality of 82 is set for the former.

The visible result is a slight softening along crisp boundaries and, at lower settings, a faint mottling in large flat fills where the encoder has decided the difference does not matter. Push the quality towards 95 for flat artwork. At these dimensions it costs single-digit kilobytes and it is the difference between a mark that looks drawn and one that looks photographed.

The alpha channel comes through: on a test drawing the corner pixel of the resulting AVIF reads 0,0,0,0, so a cut-out mark drops onto any background exactly as the SVG did. That is not universal among raster targets — the GIF path on this site turns the same corner opaque black.

It is stored as a second coded plane alongside the colour, effectively a small second image inside the container. On a photograph that overhead disappears into the noise; on a simple drawing where the whole file is a few kilobytes it is a visible share of the total, and part of why the numbers above are what they are.

Every current major browser decodes AVIF and has for several years, which is enough for most sites to serve it directly. SVG has been read by everything since well before that, and by a great deal that is not a browser: design tools, office software, ticketing systems, email clients that would show a broken image for an AVIF.

So replacing a vector with an AVIF narrows the set of things that can display the asset, and the usual mitigation — a picture element with a fallback source — means shipping two files where the SVG alone would have worked in both places. That is a real cost with no matching benefit.

The AV1 encoder is the largest WebAssembly module this site ships and the slowest to run, because making a still AVIF means performing an AV1 intra-frame search. A single 1,024-pixel drawing took about a second end to end in testing, including fetching the encoder for the first time.

For one file that is nothing. For a folder of two hundred illustrations it is a genuine wait, and it repeats on every build if this sits in a pipeline. Worth weighing against the byte result rather than separately from it — spending build time to make a vector larger is a poor trade in both directions.

Drop the folder. Every drawing is rendered at the same scale and encoded with the same quality, and the results come back as a ZIP. A shared scale is what an illustration set usually wants, since consistency across the set reads better than any single file being individually optimal.

Their proportions will not match unless the source viewBoxes did — the scale fixes the width and the height follows each drawing — so check the dimensions before wiring them into a grid that assumes a common aspect ratio. And keep the SVGs: they are the master copies, and the AVIFs are an export that can be regenerated at any size.