Home · Blog · Transparency guide
Transparency, explained: alpha channels without the headache
27 Sep 2026 · Images · 7 min read
Everyone has met the white-box surprise. You have a logo with a nice transparent background. You convert it to JPEG — for email, for an upload form, for whatever reason — and the transparency is gone, replaced by a flat white rectangle that looks broken on any non-white background. Nothing warned you. The file just quietly dropped the information and carried on.
Transparency in digital images is handled by something called the alpha channel, and the rules for which formats keep it are simple once stated — but almost nobody states them, so people learn by getting burned. This article states them: what the alpha channel is, which formats preserve it, what happens in the ones that don't, and how to convert without surprises.
What transparency actually is
A digital image pixel is usually described by three numbers: red, green and blue. A pixel with transparency gets a fourth number — the alpha value — which records how opaque that pixel is. Fully opaque is 255, fully transparent is 0, and the 254 values in between describe every shade of semi-transparency: the soft edge of a drop shadow, the anti-aliased curve of a letterform, the frosted-glass effect.
That fourth channel is just data, like the other three, which means a format either stores it or it doesn't. There is no middle ground and no clever workaround: if the format has no alpha channel, transparent pixels must become something when saved, and that something is decided by the converter — usually white, sometimes black, occasionally the nearest opaque colour. The white box is not a bug. It is the format telling you, in its own blunt way, that it never supported transparency at all.
Which formats keep it, and which don't
| Format | Transparency | Notes |
|---|---|---|
| PNG | Full alpha | The classic choice. 8-bit alpha, lossless — transparency exactly as authored. |
| WebP | Full alpha | In both lossy and lossless modes. Smaller files than PNG for the same result. |
| AVIF | Full alpha | Excellent compression, but tooling and support are still catching up. |
| SVG | Full alpha | Vectors describe transparency mathematically; always exact. |
| GIF | 1-bit only | A pixel is either fully transparent or fully opaque — no soft edges. Fine for pixel art, terrible for shadows. |
| JPEG | None | No alpha channel exists in the format. Transparent areas get flattened, usually to white. |
| BMP | None (usually) | Theoretically possible in some variants; in practice, assume none. |
The practical upshot: if your image has any transparency worth keeping — a logo, an icon, a cut-out, anything with soft edges — your target format must be PNG, WebP, AVIF or SVG. JPEG is never the answer for these images, no matter how tempting the file size.
The JPEG trap, in detail
Converting a transparent image to JPEG forces a decision the format cannot represent, so the converter makes it for you: every pixel's colour is composited against a background, and the alpha channel is discarded. The default background is white in nearly every tool, which is where the white box comes from.
Sometimes white is exactly what you want — a logo destined for a white page, for instance. But consider a dark-mode website, a coloured slide background, or a photo collage: the white box looks like a mistake because it is a mistake, just one you made three steps ago when you chose the format. The fix is not a better JPEG converter. The fix is not converting to JPEG at all.
If you genuinely need a JPEG of a transparent image — some upload forms accept nothing else — composite it against the actual background colour it will sit on, not white by default. A logo flattened onto the exact dark blue of your site header looks perfect on that header. This is called choosing a matte colour, and it's the professional version of the white box: same technique, deliberate choice.
The subtler problem: halos and fringes
There is a second transparency trap that catches even careful people. Anti-aliased edges — the smooth curves of text and logos — are made of semi-transparent pixels whose colours were blended against the background the designer was using. A white logo designed on a white artboard has edge pixels that are whitish and semi-transparent; placed over a dark background, those edges show as a faint light halo.
This isn't a format problem — PNG preserves those pixels perfectly. It's an authoring problem: the edge colours carry an assumption about the background. The defence is to design (or request) the asset against a background close to its final use, or to use artwork with clean vector edges (SVG) that re-renders correctly anywhere. When you receive a logo with a halo, the polite fix is to ask the designer for a version made for dark backgrounds, not to scrub at it in an editor.
Transparency and file size
One more thing worth knowing: transparency costs bytes. An alpha channel is a fourth channel of data, and noisy or complex alpha — wispy hair cut-outs, smoke, glass reflections — compresses poorly, because there's little pattern for the encoder to exploit. A PNG with intricate transparency can be several times larger than the same image flattened.
This is where WebP earns its keep: its lossless mode typically encodes alpha 20–30% more efficiently than PNG, and its lossy-with-alpha mode is dramatically smaller still for photographic cut-outs. If transparent PNGs are bloating your pages, converting them to WebP is one of the highest-value single changes you can make — same pixels, same transparency, much smaller files.
Checking transparency before you convert
A surprising amount of transparency trouble comes from not knowing whether an image has an alpha channel in the first place. A logo on a white background might be genuinely transparent, or it might just be white pixels — and the two behave identically until the moment you place them on a coloured background, when one works and the other shows a box.
The quickest check is the checkerboard: open the image in any editor that displays transparency as a grey-and-white checkerboard pattern. Checkerboard means real alpha; solid white means white pixels, no matter what the file extension suggests. (File extensions lie cheerfully — a ".png" can contain zero transparent pixels.) You can also check programmatically: if more than a handful of pixels have alpha values below 255, the image uses transparency.
This check takes five seconds and prevents the most common version of the white-box surprise: converting a "transparent" PNG to JPEG only to discover the transparency was never there. When someone sends you a logo that "should be transparent" and it isn't, the fix is to go back to the source — the designer, the brand kit, the original export — rather than trying to delete a background that was baked in from the start.
The honest caveat
Two limitations deserve stating plainly. First, semi-transparency and lossy compression are uneasy partners: WebP's lossy-with-alpha mode is excellent, but at very low quality settings the alpha channel gets quantised too, and soft edges can develop visible banding. For critical work — a client's logo, paid advertising — lossless is still the safe choice.
Second, not every viewer honours transparency identically. Old software, some email clients and a long tail of embedded systems either ignore the alpha channel or render it as black instead of transparent. If your image must survive unknown viewers — email signatures are the classic case — flatten it onto its intended background and ship the flattened version. Transparency is a feature of the viewing context as much as of the file.
The rule that survives all of this: keep transparency in formats that support it (PNG or WebP), flatten deliberately — onto the right matte colour — when the destination demands it, and never let a converter make the choice silently on your behalf.