Case Study: Prepare a Transparent Logo for JPG, SVG, and ICO

Start with the destination’s requirement

A marketplace image slot may ask for JPG, a design handoff may ask for SVG, and a browser favicon fallback may ask for ICO. Those requests are not interchangeable. Converting the same file to each format can be technically valid while producing files with different visual and editing behaviour.

The source in this test is an 800×800 transparent PNG with a simple flat PX mark. It is deliberately clean and geometric, which makes it a favourable tracing case. A photographed logo, a low-resolution screenshot, or artwork with soft shadows would produce less predictable SVG paths.

The reason to begin with the requirement rather than the file is that each of these conversions discards something different and permanently. Choosing the format first and discovering the cost afterwards is how people end up with a logo that has a white box around it on a dark page, or a favicon nobody can identify.

What each format can and cannot hold

The three outputs differ in kind, not merely in quality. A JPG stores a fixed grid of opaque pixels; it has no alpha channel, so transparency has nowhere to live. An SVG stores shapes described mathematically; it scales to any size without additional data, but it has no concept of the photographic detail a raster image can carry. An ICO is a container holding several complete raster images at different sizes, so software can pick one rather than scaling a single source badly.

Those differences mean the conversions are not reversible in any useful sense. Flattening to JPG discards alpha permanently — converting back to PNG yields an opaque image with the white still in it. Tracing to SVG discards the pixel data and replaces it with fitted paths; converting back produces a rendering of the approximation, not the original. The ICO holds downsampled copies, so it is not a route back to the 800-pixel source.

This is why the original PNG keeps its status as the master. It is the only one of the four files that can still become any of the others.

Measured conversion results

PixelConvert received the same 11,839-byte RGBA PNG three times. JPEG conversion used quality 85 and a white background. SVG conversion used colour mode, filter_speckle=4, and color_precision=6. ICO conversion used the production size list. All three requests returned 200 from /api/v1/convert/process.

The JPEG output is 800×800 and has no alpha channel, because it was flattened onto white before encoding. The SVG output contains traced path elements; it is vector data, but it is still an approximation made from pixels. The ICO output contains the six requested resolutions so applications can choose a suitable icon size rather than scaling one source for every context.

Every output in this test is a real response from the running conversion endpoint rather than a description of expected behaviour, and all four files are downloadable below. The JPEG and ICO were reopened after conversion to verify their properties — the absence of an alpha band in one, and the six embedded sizes in the other — so the claims on this page are checks performed rather than assumptions stated.

When to use JPG

Choose JPG only when the destination explicitly requires it or when a solid background is acceptable. Before converting, choose the background colour deliberately. A white marketplace page may make white the safe choice, but a dark page, printed label, or coloured presentation can make that choice look wrong.

Do not use JPG when the logo must sit over an unknown background. Its lack of transparency means the selected background becomes part of the pixels. For a reusable web or presentation asset, keep the transparent PNG or use a genuine original SVG if one exists.

The damage is worst at the edges, which is where people tend not to look. The antialiased pixels around a mark are partially transparent, so flattening blends them with the background colour rather than simply placing them on it. The result is a thin fringe of that colour tracing the outline — invisible against a matching page, obvious against anything else, and not cleanly removable afterwards because the fringe is now ordinary opaque pixels.

There is also a size point worth noting: JPEG is a poor fit for flat graphics generally. A logo is exactly the content type where lossy compression adds visible artifacts around sharp edges while often producing a larger file than a lossless format would. Convert because the destination demands it, not because you expect a smaller file.

When to use traced SVG

Use tracing when a system genuinely requires a vector-like file and no official vector artwork exists. Inspect the result at large scale: curved edges, small counters, corners, and letters often expose approximation errors that are hidden in a thumbnail.

Do not describe a traced SVG as a recovered logo source. It does not restore fonts, layers, naming, design intent, or a licence to use somebody else’s mark. If the original designer or organisation can supply an SVG, PDF, EPS, or design file, use that instead of tracing.

Before tracing anything, spend a few minutes looking for the real vector. Most organisations of any size publish a brand or press kit containing logo files in SVG or EPS, and many websites already serve their logo as an SVG you can save directly. Tracing is what you do when the original genuinely cannot be obtained, not a shortcut past asking for it.

The quality of the source governs the quality of the trace more than any setting does. The mark used here is flat, geometric, and high-contrast, which is close to the ideal case. Artwork that has been through JPEG compression at any point carries faint halos around every edge, and the tracer will faithfully draw paths around those artifacts — producing a noisy result that no adjustment of speckle or precision fully repairs.

When to use ICO

Use ICO for a browser favicon fallback or software that specifically asks for an icon container. The important test is at 16 and 32 pixels, not at the full 800-pixel source size. Simplify a complex wordmark before conversion; thin details and tiny text disappear at tab scale.

Browsers cache favicons aggressively. If you replace a favicon and still see an old mark, test in a private window, hard-refresh, or use a changed filename. That usually indicates cache behaviour, not a failed ICO conversion.

The reason the container holds six sizes rather than one is that the same file is used in places with very different dimensions — a browser tab, a bookmark list, a pinned shortcut, a desktop icon. Supplying each size separately lets the software choose an appropriate one instead of downscaling a single large image, which is where soft, muddy favicons come from.

A larger source does not rescue an unclear favicon. Downscaling to 16 pixels averages away detail regardless of where it started, so a 1024-pixel source and a 256-pixel source produce near-identical results at tab size. What helps is changing what is being averaged: thicker strokes, fewer shapes, higher contrast. That is a design change, not a resolution change.

Keeping the four files straight

One conversion session has now produced four files from one logo, and the common failure afterwards is organisational rather than technical: six months later nobody can tell which is the master.

Name derivatives so their purpose is obvious from the filename — including the format and, where it matters, the background colour or the destination. A file called logo-white-bg.jpg is self-explanatory in a way that logo2.jpg is not, and the distinction matters most to whoever inherits the folder.

Store the original PNG apart from the derivatives, and do not edit it. Everything else is reproducible from it in minutes; it is the only file that is not reproducible from anything else. If a destination later changes its requirements, you regenerate rather than reconstruct.