Convert AVIF to SVG

This is the only conversion in the AVIF family where the file you hold decides whether the exercise is worth starting. Tracing works by finding the edges between areas of similar colour and drawing an outline around each one. Artwork that was drawn — a logo, an app icon, a badge, a scanned pen drawing, a flat chart — is full of such edges and traces cleanly.

A photograph is not. Every region of a photograph is a gradient, so there are no edges to find and the tracer manufactures them by flattening the picture into bands of colour first. The result is a posterised copy assembled from thousands of paths, each one a boundary that does not exist in the subject and only exists because the flattening put it there. That is not a flaw in the implementation; it is what tracing is, and no setting on this page changes it. The honest recommendation for a photograph is to convert it to PNG or TIFF and keep the pixels.

AVIF exists to make web pages lighter, and the pictures that make web pages heavy are photographs. Sites reach for it for hero images, product shots and article headers, so the typical AVIF in circulation is exactly the material tracing handles worst. It is also the format servers hand over when a browser says it will accept one, which means the visitor never chose it and often does not know what the original was. Anybody who arrived here after saving an image off a page should check what the image actually is before going further.

The exception is worth naming because it is the whole reason this page exists. Build pipelines convert every asset in a directory, logos and icons included, and a designer handed the output has a flat mark trapped in a photographic delivery format. That file traces beautifully, and getting it back to vector is a real recovery rather than a novelty.

Every other pair on this site takes one representation of a picture and writes another representation of the same picture. This one reads the picture and draws something new that resembles it. Nothing in the SVG came out of the AVIF unchanged — not a pixel, not a colour boundary, not an edge.

The practical consequence is that the output has to be looked at rather than trusted. A conversion to TIFF or BMP can be assumed correct because the pixels are carried across; a trace can be a clean recovery of a logo or an unusable approximation of one, and the only way to tell is to open it. Look at it at the size it will actually be used, which for a traced file usually means much larger than the AVIF was ever displayed — the failures of a trace are invisible at thumbnail size and obvious on a banner. Keep the AVIF until you have done that.

Four colours suits a single-colour mark, a monogram or a two-tone logo, and produces the fewest paths and the smallest file. Eight is the default and the right answer for most flat illustrations. Sixteen and thirty-two keep more shading and multiply the path count accordingly.

The instinct to raise the number is usually wrong. Each extra colour band adds another layer of outlines stacked over the ones beneath, so a setting of thirty-two on artwork that only ever had five colours produces a file that is larger, slower to open and no more faithful. The extra bands go into the anti-aliased fringes at the edge of every shape, which is where a lossy AVIF is least accurate to begin with, so the added paths describe compression artefacts rather than the drawing. Start at four or eight, look at the result, and raise it only against something you can see is missing.

The detail setting controls how tightly the traced outlines hug the pixel grid. Smooth rounds the curves and discards the smallest specks, balanced is the default, and sharp follows the pixels closely enough that a staircase in the source becomes a staircase in the vector.

Which one is right depends on how the AVIF was made. An asset that went through lossy AVIF compression carries faint blocking around hard edges, and sharp faithfully traces that damage into permanent path nodes; smooth throws it away along with a little genuine detail. For anything saved off a website, smoothing is generally the better trade. Sharp earns its place on a clean source — an AVIF written losslessly, or a screenshot of an interface where the pixel grid is the drawing rather than an artefact of it, and where rounding the corners would be the loss.

AVIF has a full alpha channel and SVG has no background at all, so a cut-out mark stays cut out: the areas that were transparent are areas no path covers, and whatever the SVG is placed on shows through.

Semi-transparent pixels are the awkward part. Anti-aliasing along a curve is a band of partly transparent pixels, and a tracer working in flat colours has to resolve each one either into the shape or out of it. Edges therefore come back slightly harder than they went in, which is invisible at sign size and occasionally visible at the size the original was drawn. Where the AVIF had a genuine soft shadow or a faded edge, expect it to arrive as a series of concentric flat bands instead, and to look like a mistake unless the colour count is dropped to four.

A logo that AVIF stored as forty thousand pixels can leave as thirty path commands, and the SVG is then a fraction of the size and sharp at any dimension. That is the good case and it is common with the artwork this page is written for.

The bad case runs the other way and runs a long way. An SVG is XML, so every shape is spelled out in readable text with its coordinates written as numbers, and a traced photograph is a document listing thousands of them. Text describing that many shapes takes far more room than a codec built to compress photographs, and the gap is often an order of magnitude. The comparison is made for you after the trace finishes and shown before you download anything, which is the fastest available answer to whether this was a good idea.

It opens in Inkscape, Illustrator and Figma, and every path is selectable and recolourable. What it is not is structured. A drawn logo has a circle, a wordmark and a background as separate named objects; a traced one has a stack of colour regions that happen to look like those things.

So it is good for scaling, printing large, cutting and recolouring in bulk, and poor for editing a letterform or adjusting one element of a lock-up. Text is the clearest case: a traced wordmark contains no text at all, only outlines shaped like letters, so it cannot be reset, respaced or corrected for a spelling mistake. If the person who made the original still has the source file, one email is worth more than any setting on this page.

If the AVIF came off a site you control, the build pipeline that produced it started from something, and that something was probably an SVG or an editor document. Recovering it costs nothing and loses nothing.

If the goal is a large print rather than an editable file, tracing may not be needed at all. AVIF holds up to 65,536 pixels on a side, so a source at a sensible resolution is often already big enough for the poster, and a straight conversion to TIFF or PNG keeps the picture instead of reinventing it. The rule of thumb is what the file is for: tracing is right when the artwork has to be redrawn, scaled without limit or cut by a machine, and wrong when it merely has to be printed once at a known size.

Drop a folder of icons and each is traced in turn with the same settings, returned together as a ZIP. That suits an asset set converted wholesale into AVIF by a pipeline, which is the situation that produces most of the good inputs for this page. One caution about batches: the settings apply to every file equally, and a directory that mixes flat icons with photographic headers will produce good vectors and useless ones in the same archive.

All of it runs on your own processor, so nothing is uploaded and there is no queue, no account and no daily allowance. It also means the settings can be changed and the trace run again in seconds, which matters here more than on any other pair: the first result is rarely the one you keep.