Convert WebP to SVG

The WebP on this page nearly always came from a website, and websites that serve WebP are usually built by someone who also has the vector. Three places are worth checking and all three take under a minute: request /favicon.svg on the domain, open the page source and search for ".svg", or watch the network panel while the page loads and look at what it fetched.

A great many sites ship their logo as inline SVG in the HTML, which means the actual artwork — real curves, real text, named shapes — is sitting in the markup and can be copied straight into a file. A traced copy is a reconstruction with outlines where letters were and fitted segments where curves were. When the original is one view-source away, taking it is strictly better than approximating it, and this page is for when it is not.

WebP is two formats sharing an extension: a still image and an animation, and plenty of the little looping graphics on the web are the second kind. The decoder used here is libwebp’s still-image path with no demuxer attached, so an animated file is not partially converted — it is refused, and you get a readable "could not read this file" message rather than a silent first frame.

That is the better failure of the two available, and it is deliberate elsewhere on the site too. Both a lossy and a lossless animation were tested against the decoder and both were rejected. If you need the motion, WebP to GIF or WebP to MP4 keeps it. If you only wanted one frame to trace, open the animation in a browser, pause it, screenshot the frame you want and trace the screenshot — bearing in mind that a screenshot is itself a poor tracing input if it contains text.

WebP can be encoded either way and the extension does not tell you which. A lossless WebP is a PNG-equivalent: the edges in the file are the edges the designer drew, and it traces about as cleanly as an export. A lossy WebP has been through a transform that smooths flat areas and rings along hard boundaries, exactly as JPEG does, and those ripples are structure as far as the tracer is concerned.

The symptom is a logo whose outlines look slightly quilted, with small satellite shapes hugging every edge that should have been crisp. Smooth detail removes most of them because they are small, and a lower colour count removes more because there are fewer palette entries for the ripple to occupy. Neither recovers the original edge. If the site also serves a PNG of the same asset — many do, as a fallback in a `<picture>` element — that PNG is the better file to trace.

Sites serve images at the size the layout uses, often through a resizing service, and WebP exists precisely so that size can be as small as possible. A header logo delivered at 240 or 320 pixels wide is normal, and that is all the information the tracer has to fit outlines to.

The consequence is that corners round off and thin strokes wobble, and no setting on this page fixes it, because the fix is more pixels. Before converting, try the obvious things: request the same file with a larger width parameter in the URL, look for an @2x or @3x version, or check whether the site has a press or brand page — organisations that publish one almost always publish an SVG or an EPS there. Anything longer than 1,600 pixels is scaled back down before tracing, so there is no benefit past that, but the gap between 320 and 1,600 is real and visible.

Four for a single-colour or two-colour mark, eight for a flat illustration or a badge with a few fills, and higher only when something is visibly gone. Eight is the default and is a reasonable first attempt for most things saved off a page.

On a lossy WebP the argument for staying low is stronger than usual. Every extra palette entry gives the quantiser somewhere to put the compression ripple, so raising the count from eight to sixteen frequently adds shapes that are made entirely of artefact. Try four first on anything that looks like a logo; if the mark survives it, that is both the smallest file and the cleanest set of paths to tidy up afterwards.

The detail setting decides how closely each outline follows the pixel grid and how small a shape must be before it is discarded. Smooth fits loosely and drops anything under sixteen pixels; sharp follows the grid closely and keeps shapes down to two pixels; balanced is the default between them.

Smooth is the right default for this page, because the specks a downloaded WebP produces are compression artefacts rather than design. Sharp is worth trying only on a lossless WebP of a pixel-precise icon, where a two-pixel feature is genuine. The tracer never blurs the image before working on it — the blur radius is fixed at zero — because pre-blurring reduces the speck count by destroying the hard edges that were the reason to trace a logo in the first place.

A stack of filled paths, each with a solid fill and a matching one-pixel stroke, plus a full-canvas path at zero opacity where the WebP was transparent. No groups, no names, no text elements, no gradients. A wordmark comes back as letter-shaped outlines, so it can never be re-set in the original typeface; a gradient comes back as bands.

For a slide, a large print, a cutter or a placeholder that has stopped going soft, that is usually enough. As a brand asset it is not, and a designer will identify it as a trace on sight. Where the mark is going back into any system that will be looked at closely, treat the SVG as an accurate template to redraw over: most logos are a few geometric shapes and a typeface, and rebuilding them from a good trace is faster than cleaning one up.

This page gets used for two things that look identical to the converter and are not the same at all. Recovering your own artwork — the mark from a site you own, or one an agency built and no longer supports — is the ordinary case and nobody has a problem with it.

The other case is rebuilding somebody else’s brand asset from their website, and tracing it does not change who owns it. That is worth settling before the file goes into a design rather than after. It is also the reason this conversion runs entirely in your browser: whatever the file is, it does not leave the machine, and there is no server-side copy of a logo somebody may not have wanted shared.

If the image is a photograph, tracing will posterise it and enlarge it; WebP to JPG or WebP to PNG is what that situation actually needs, and WebP to JPG is the usual answer when something downstream simply refuses the format. If it is a screenshot with text in it, tracing is the worst possible move — WebP to TXT reads the words instead.

If the goal is a favicon, WebP to ICO produces the file directly and does not need a vector step first. And if the goal was just to have the picture in something ordinary software opens, WebP to PNG keeps every pixel with nothing lost. Tracing earns its place only when the artwork is flat and genuinely has to scale or has to be cut.

Decoding, scaling and tracing all happen in the tab. The WebP decoder is libwebp compiled to WebAssembly and fetched only when a WebP is dropped, so nothing about the image is sent anywhere and there is no account or daily allowance in the way.

The tracing itself is imagetracerjs: 46 KB of pure JavaScript under the Unlicense. It is not the strongest tracer available — potrace and autotrace fit better curves and are GPL, and VTracer is better than both but ships a browser build with no licence declared at all, which this project treats as blocked rather than permissive. On a flat mark the difference between them is small, and on a lossy WebP the compression matters more than the tracer does.