Convert GIF to SVG

Tracing works by finding the boundaries between areas of similar colour and drawing an outline around each area. That means it is at its best when those areas genuinely exist, with hard edges and no subtle variation across them.

An indexed image is exactly that by construction. A GIF frame is drawn from a palette of at most 256 entries, so every pixel is one of a small set of exact values and the regions are already flat before the tracer looks at them. The limitation that makes GIF a bad photographic format is, for this one conversion, the thing that makes it a good source.

It is worth being precise about what comes out. The SVG is not the drawing somebody made in 1998 and exported as a GIF; it is a new set of paths fitted to the pixels of that export. Where the original had a perfect circle, the trace has a closed curve that follows a circle made of pixels.

At the sizes people actually use these files that difference does not show. What does show is anywhere the original had something a path cannot represent — a gradient becomes a set of stepped bands, a drop shadow becomes several concentric shapes, and antialiasing along a curve becomes a thin extra outline in an intermediate colour.

The colours option reduces the picture to that many flat fills before any outlines are drawn, and it is the setting with the largest effect on both the look and the size of the result. Four gives the cleanest possible shapes and is right for a single-colour mark. Eight is the default and covers most logos. Sixteen and thirty-two follow the source more closely and multiply the number of paths.

The instinct to pick the highest number is usually wrong. More colours means the antialiased fringe around every edge gets its own shapes rather than being absorbed into the fill on either side, and those shapes are both the bulk of the file and the first thing you would delete by hand. Starting low and going up only if something important disappeared is the faster route.

The detail setting controls two error thresholds and a minimum shape size. Smooth accepts a looser fit to the pixel edges and discards any shape smaller than sixteen pixels; balanced halves those tolerances and drops shapes under eight; sharp follows the pixels closely and keeps anything above two.

The practical effect is on speckle. Antialiasing leaves a scatter of one-pixel and two-pixel fragments along every edge, and on sharp they all become paths — hundreds of them, invisible individually and responsible for most of the file size. Smooth removes them and rounds the corners slightly in the process. For a logo that will be scaled up, smooth is almost always the better answer; for pixel art you actually want to preserve, sharp is the only one that keeps it.

If the GIF was made from a photograph or a gradient, the encoder almost certainly dithered it — scattering pixels of two palette colours in a checkerboard so the eye averages them. That looks like a smooth transition and it is not one.

To a tracer it is thousands of tiny alternating regions, each of which becomes a path. The output is enormous, the file takes a long time to draw, and the visual result is a posterised mess rather than the gradient it was imitating. This is the single reliable indicator of whether this conversion will work: zoom into the GIF, and if the flat areas turn out to be checkerboards, stop here.

Anything with a longest edge above 1600 pixels is scaled down to that before the outlines are found. Tracing cost grows with the number of edges rather than with the file size, and a large image has an edge almost everywhere, so without a ceiling a big source produces a multi-megabyte SVG over tens of seconds.

For this conversion the ceiling costs nothing, and that is not a hedge. The output is resolution-independent: a mark traced from a 1600-pixel image and the same mark traced from a 4000-pixel image render identically at any size on screen or in print. All that changes is how tightly the paths hug the original pixel grid, which is a difference you would need to zoom in on the source to see.

A screenshot containing text was measured at forty times the size of the source image when traced. Every antialiased letter becomes its own collection of shapes, the counters inside letters become separate paths, and the result is both huge and slightly wrong at every stroke.

The right move when the graphic contains words is to trace only the symbol and set the words as real text in the SVG afterwards, in the actual typeface. That produces a smaller file, sharper output at every size, and something that can be edited or translated later. Tracing the text is only reasonable when the lettering is genuinely custom artwork rather than a font.

Nothing here tries to predict whether your particular GIF will trace well. A colour-count heuristic would be a guess, and the real answer is available a moment later for free: trace the file, then look at what came out against what went in.

The page shows both sizes, so a result that is forty times larger announces itself immediately. Treat that as the signal rather than as a curiosity — an SVG bigger than its source is telling you the picture had no flat regions to find, and no combination of settings will change that fact about the image.

The tracer is a small JavaScript library — 46 KB, chosen partly because the better alternatives are licensed in ways a static site cannot honour — and it runs in the tab. The GIF is decoded, reduced, traced and written out as SVG without a request leaving your browser.

The practical benefit beyond privacy is speed on small files. There is no upload, no queue and no download of the result from somewhere else, so a logo traces in well under a second and trying three different colour counts costs nothing but the clicks.