What happens to transparency when you save a PNG as JPG

Your logo had a clean transparent background. Now it has a white box around it. This is not a bug in whatever tool you used — it is JPG doing the only thing it can.

Updated 28 August 2026 · 10 min read

The logo was fine in the design file. It was fine as a PNG. Then someone asked for a JPG, and now it has a white box around it — or worse, a black one, or a grubby grey fringe that follows every curve of the lettering. Nothing was corrupted and nobody made a mistake. The file format simply has nowhere to put the information you lost.

This is one of the few image problems with a genuinely clean explanation. Once you know what an alpha channel is and why JPEG has no room for one, the white box stops being a bug and becomes a predictable consequence you can steer.

What transparency actually is inside the file

A normal pixel carries three numbers: how much red, how much green, how much blue. Three numbers, eight bits each, and that is a colour. A PNG can carry a fourth number alongside them — the alpha channel — which records how opaque that pixel is. Also eight bits, which gives 256 possible levels, from fully invisible at 0 to fully solid at 255.

The middle of that range is the part people underestimate. Transparency is not a yes-or-no property. The edge of a circular logo is not a jagged staircase of solid pixels and empty ones; it is a band of pixels at 20%, 60%, 90% opacity that blend the shape into whatever sits behind it. That band is what makes a curve look like a curve rather than a flight of tiny steps. A soft drop shadow is the same idea stretched over fifty pixels instead of two — a smooth ramp from nearly opaque to nothing at all.

So an image with transparency is really two pictures stored together: the colours, and a greyscale map of where those colours should be visible. The map is why a PNG logo can be dropped onto a dark navy header one week and a cream brochure the next and look correct on both.

Why JPG cannot hold it

JPEG has no alpha channel. Not a disabled one, not one that requires a special export setting — there is no field in the file structure where per-pixel transparency could be written. The format was designed in the late 1980s and standardised in 1992 for photographs, and a photograph is an opaque rectangle. Nothing in the specification anticipated a picture with holes in it.

This matters because it means no software can save a transparent JPG, however expensive it is or however you configure it. If a tool appears to offer the option, it is either producing a different format under a .jpg filename or it is quietly making a decision on your behalf about what colour to put in the gaps. There is no third possibility.

The technical term for that decision is flattening: compositing the transparent image onto a solid background so that every pixel becomes fully opaque, and the alpha channel becomes unnecessary. After flattening there is no transparency left to lose, which is exactly why the JPG can then be written without complaint.

Why the replacement colour is different in every program

Here is the part that generates most of the confusion. Two people can convert the identical PNG in two different tools and get two different results — one clean on white, one with a black rectangle. Neither tool is broken.

Broadly, three behaviours exist in the wild, and which one you get depends entirely on the software:

• Fill with white. The most common choice, and usually the least surprising, because most documents and most web pages are white already.
• Fill with black. Also common, and it comes from treating the missing channel as zero. Zero red, zero green, zero blue is black.
• Keep whatever was already in the RGB channels. This one produces the strangest results, and it needs explaining.

Remember that a transparent pixel still has red, green and blue values stored next to its alpha value. When alpha is 0, those three numbers are invisible — nothing displays them, so nothing constrains them. Different editors and different export routines leave different things there. Some write black. Some write white. Some leave a smeared copy of whatever colour was nearby before the area was erased, because their internal compositing never bothered to clean up pixels that would never be seen.

Flattening in a way that ignores alpha and simply keeps the RGB values exposes all of that hidden material at once. That is the mystery solved: the black box, the mysterious coloured rectangle, the halo of dirty pixels tracing the outline of a shape that was deleted three revisions ago. It was always in the file. It just had no reason to be visible until the alpha channel was thrown away.

The practical consequence is that you cannot reason about what a JPG conversion will look like from the PNG alone. You have to look at the output. And if you are converting a batch of logos for a client, you have to look at more than the first one, because the garbage under the transparency is not necessarily consistent across files from different sources.

Where the damage actually shows

Flattening is not automatically destructive. A logo that is a hard-edged shape with no anti-aliasing, flattened onto exactly the background it will sit on, comes out indistinguishable from the original. Many conversions are completely harmless and nobody notices, which is why the advice "just send it as a JPG" survives.

The trouble concentrates in the partially transparent pixels — the ones between 1 and 254.

Anti-aliased edges. The blend band around every curve and diagonal is mathematically a mixture of the shape's colour and the background's. Flatten a logo with soft black lettering onto white and each edge pixel becomes a shade of grey. Place that JPG on a dark background and those greys read as a pale fuzz outlining every letter. The shape is intact; its edges are wearing the memory of the wrong background.

Soft shadows and glows. A drop shadow is a wide field of low-opacity pixels. Flattened onto white it becomes a wide field of pale grey — and because a shadow's bounding area is usually rectangular, you get a visible rectangle of slightly-off colour when the image is placed on anything that is not that exact white. This is the classic "why does my logo have a box around it" case, and it is almost always a shadow rather than the logo itself.

Near-white and near-black artwork. A white logo flattened onto white is not subtly wrong; it is gone. It converts to a blank rectangle, and this happens more often than it should because the person exporting is looking at a preview on a dark editor canvas.

JPEG compression then makes all of this slightly worse, because the encoder is tuned for photographs and handles hard colour boundaries poorly. Flat colour next to sharp edges is the worst case for it — the same reason a screenshot of text saved as JPG looks smeared. If your image is a logo or a diagram, the format is fighting you on two fronts at once, and the comparison of what each format is genuinely good at is worth reading before you commit.

How to decide: keep alpha, or flatten on purpose

The decision comes down to one question — do you know exactly what colour this image will sit on?

If yes, flatten deliberately onto that colour. A logo destined for a white slide deck should be flattened onto white, and it will look perfect. If no, or if the answer is "several different backgrounds", keep a format with an alpha channel and refuse the JPG request.

GIF deserves its own note because it is the origin of a persistent misunderstanding. Its transparency is a single flag per pixel — visible or invisible, with no in-between. There is no partial opacity, so edges cannot be smooth, which is why old GIF logos have that characteristic crunchy outline. When people say transparency "always looks rough", they are usually remembering GIF.

WebP is the answer worth knowing about, because it keeps a proper alpha channel while compressing far more efficiently than PNG. If your PNG logo is unexpectedly heavy, transparency is often part of the reason, and there are several other reasons a file balloons that are worth ruling out too.

What to do when the JPG is all you have

Flattening is irreversible. The alpha channel is not compressed or hidden in the JPG — it was discarded before the file was written. No setting, no tool and no amount of re-saving will bring it back, because the information is not there to recover. If you need transparency again, you need the original.

That is worth saying plainly because "remove the white background" is offered so casually. Removing a background from a flattened JPG is a completely different operation from never losing the transparency. It is a guess: an algorithm examines the pixels, decides which ones look like background, and deletes them. On a hard-edged black logo on clean white it guesses well. On anything with a soft shadow, a gradient, or edge pixels that are now some shade of grey because they were blended with the old background, it guesses badly — and JPEG's own compression artefacts around those edges give it further noise to misread.

So the order of preference is: find the original file; if you cannot, ask whoever made it; and only then reach for a background remover, expecting to touch up the result by hand.

Practically, this argues for keeping a master copy in a format with alpha and generating flattened JPGs from it as needed, rather than the other way around. Exports are cheap and repeatable. Restorations are neither. If the JPG requirement comes with a file size limit attached, that is a separate problem with its own reliable method, and it should be solved after you have decided what the background will be, not before.

Common questions

Can I save a transparent JPG if I use better software? No. There is no field in the JPEG file format capable of storing per-pixel transparency, so this is not a limitation any program can work around. Anything claiming otherwise is producing a different format or filling the gaps for you.

Why did mine come out black instead of white? Because the software either treated the missing channel as zero, or kept the raw RGB values that were sitting underneath the fully transparent pixels. Those hidden values are undefined in practice and are frequently black, which is why this outcome is so common. Converting the same file elsewhere may well give you white.

The white background looks right, but the edges look fuzzy on my dark website. Why? The anti-aliased edge pixels were blended with white during flattening and are now pale grey. They are permanently part of the picture. The fix is to use the PNG, or to re-export from the original onto the dark colour instead.

Does WebP really keep transparency even when it is lossy? Yes. Unlike JPEG, WebP stores the alpha channel separately from the colour data, so you can have lossy compression and a proper transparent background at the same time. It is the practical middle ground between a large PNG and a flattened JPG.

Should I just always use PNG then? Not for photographs. PNG is lossless and will produce a file several times larger than a JPG of the same photo with no visible benefit. Use PNG when transparency or pixel-exact detail matters, and a lossy format when it does not.

Someone asked for a JPG but the logo needs a transparent background. What do I tell them? That those two requirements cannot both be met, and ask what colour the image will sit on. Nearly always they want a file that opens everywhere rather than a JPG specifically, and a flattened JPG on the correct background solves it. If the answer is "lots of different backgrounds", they need a PNG whether they realise it or not.