Does WebP support transparency? Yes. It carries transparency in both its lossless and its lossy modes, using a full 8-bit alpha channel, the same per-pixel transparency PNG carries. What no format before it managed is lossy transparency, so a WebP logo keeps a clean transparent edge while its file drops to roughly a third the size of the same PNG.
That answer surprises people who know WebP only as the smaller JPEG replacement. I run both WebP modes daily through the compression engine behind imagecompressor.tools, and alpha is built into the format from the start, unlike JPEG, which has no transparency channel at all. This page is the deep dive from the WebP and AVIF hub: how the alpha channel works in each mode, whether a transparent WebP really beats a PNG on size, how to make and keep one, and the black background gotcha that makes people think transparency broke when it did not.
How does WebP transparency actually work?
WebP stores transparency the same way PNG does, with an alpha channel: one extra value per pixel that records how see-through that pixel is, from fully opaque to fully clear. Google's WebP format carries that channel in both compression modes (Google for Developers, WebP), which is the part that trips people up, because most formats give you transparency in one mode or none.
The alpha channel and its 8-bit depth
Alpha is a fourth channel riding alongside the red, green, and blue that make the visible color. Where RGB says what color a pixel is, alpha says how much of it shows through whatever sits behind it. WebP's alpha is 8-bit, meaning 256 levels of opacity per pixel, which is exactly PNG's precision. The WebP FAQ confirms the format uses an 8-bit alpha channel, and that animated WebP pairs 24-bit RGB color with that same 8-bit alpha. So a soft shadow or a feathered edge that needs 200 shades of partial transparency gets all 200 in WebP, not a hard on or off mask.
Lossless WebP works in RGBA
Lossless WebP handles transparency by working exclusively in RGBA, red, green, blue, and an alpha byte for every single pixel, with nothing thrown away and no color subsampling. That full fidelity is why lossless WebP with a complete alpha channel costs about 22 percent more bytes than the same image saved without transparency: the encoder is carrying one extra full-resolution channel of real data, not a rough cutout laid over the top. On a real file that premium is modest. A graphic that compresses losslessly to 500 KB with no transparency comes back near 610 KB once you add a full alpha channel, still smaller in most cases than the PNG it replaces, because lossless WebP already runs meaningfully smaller than PNG before alpha even enters the math.
Does WebP support transparency in lossy mode too?
Yes, and this is the genuinely new thing WebP brought to the web. Lossy WebP keeps a full alpha channel while compressing the color hard, so a transparent graphic can use lossy compression and still stay transparent. No format before WebP could do that: PNG is lossless only, and lossy JPEG has no alpha channel at all.
How lossy WebP transparency works
Lossy WebP transparency works by splitting the file into two parts that compress separately. The color data goes through the lossy encoder as Y'CbCr, the same color math WebP uses for photographs, while the alpha plane rides along on top, compressed on its own track and untouched by the color-side loss (Google for Developers, WebP). That separation is the trick: you get aggressive size savings on the color, which is where the bytes are, without smearing the transparency mask that defines the shape. The payoff is size. Google reports a lossy WebP with transparency is typically about 3 times smaller than an equivalent PNG. Run that on a real number: a 300 KB transparent PNG, a fair size for a mid-size logo or icon, lands near 100 KB as a lossy WebP with the same alpha coverage. The WebP compressor here keeps the alpha channel intact in either mode, so you can test the ratio on your own file with one drag and drop.
Is a transparent WebP smaller than a transparent PNG?
Almost always, yes, and by a wide margin in lossy mode. WebP's alpha channel matches PNG's precision exactly, 8-bit in both, so the difference between them is bytes, not transparency quality. Google's own lossless and alpha study measured lossless WebP at about 26 percent smaller than PNG across its test corpus (Google WebP lossless and alpha study), and lossy WebP with alpha pulls further ahead again.
Here is the same transparent graphic expressed across the three formats, using Google's published ratios rather than a fresh test on your file, so the exact bytes will shift with your image but the ranking holds every time.
| File | Relative size | Versus the PNG | Source of the ratio |
|---|---|---|---|
| Transparent PNG-24 | 100 percent | baseline | reference point |
| WebP lossless, with alpha | about 74 percent | roughly 26 percent smaller | Google lossless and alpha study |
| WebP lossy, with alpha | about 33 percent | roughly 3 times smaller | Google WebP documentation |
The one thing the table cannot show is edge fidelity, which is the real question for a logo. In lossless mode the alpha edge comes back exactly as it went in, pixel for pixel. In lossy mode a very aggressive quality setting can soften a hard alpha boundary slightly, the same faint fringe a PNG quantizer can leave, so a crisp wordmark is worth checking at full zoom before you ship it at the lowest quality that still looks right. For soft-edged art, gradients, or anything photographic, lossy WebP is the clear pick and the edge never suffers.
When lossless still wins
Reach for lossless WebP when the graphic is flat color with hard edges, a simple icon, a wordmark, a UI sprite, where every boundary must stay razor sharp and the file is small enough that the lossy saving does not matter much. Reach for lossy WebP when the image has soft edges, shadows, or photographic detail, where the size win is large and the eye never catches the difference. The honest rule is to test both on the actual file, because the size gap is big enough to be worth thirty seconds of comparison.
How do you keep transparency when converting a WebP?
Convert a transparent WebP to PNG and the alpha channel survives intact, because PNG is the other mainstream format built around full per-pixel transparency. Convert it to JPEG and the transparency is gone for good, since JPEG has no alpha channel and fills every transparent pixel with a solid color, usually white or black, baked into the file with no way back. MDN spells this out: JPEG cannot store transparency, so PNG is the format to convert to when you need to keep it.
The PNG landing format
If a logo or icon has to leave WebP for a tool or platform that will not read it, PNG is where it lands, not JPEG. You keep the alpha channel, you keep the 8-bit precision, and the only cost is a larger file than the WebP you started from. Converting to WebP the other direction, from a transparent PNG, is where you gain: turn a PNG into WebP and the alpha rides across cleanly while the file shrinks. When you do need the PNG back out, converting WebP to PNG preserves the transparency both ways.
The exact option for hidden pixels
There is one subtle behavior worth knowing. By default, WebP's lossless encoder is allowed to change the RGB color values sitting behind a fully transparent pixel, alpha equal to zero, since nothing displays there and rewriting those hidden values helps compression (Google WebP FAQ). Most of the time that is the right trade, because nobody sees a pixel at zero opacity. The exception is any workflow that reads pixel data programmatically, a game engine rebuilding a sprite sheet or an image pipeline that might later turn a pixel's opacity back up. For those, WebP's exact option locks the hidden RGB values in place, at the cost of a slightly larger file, so what goes in comes back out unchanged, transparent pixels included.
Can you make WebP transparent yourself?
Yes. Any image editor or converter that reads an alpha channel can output a transparent WebP, and the source just needs to already have transparency, usually a PNG or a layered file with no background. The transparency is not something WebP adds; it is something WebP preserves from whatever you feed it.
Exporting from Photoshop, GIMP, and the browser
In Photoshop, remove or hide the background layer so the canvas shows the checkerboard, then export to WebP through the WebP plugin or Save a Copy, keeping the alpha channel. In GIMP, which reads and writes WebP natively, delete the background, then use File then Export As and give the filename a .webp extension; the export dialog exposes lossless or lossy and keeps the alpha either way. If you would rather not open an editor, a browser-based converter that supports alpha does the same job: feed it a transparent PNG and choose WebP as the output. A converter that preserves alpha, including the one here, gives you a transparent WebP out from a transparent PNG with no setting to hunt for.
Starting from a photo with a background
If your source is a normal photo with a solid background, no converter can invent transparency that is not there. You first cut out the background in an editor or a background remover, which produces a transparent PNG, and only then convert that PNG to WebP. The order matters: make it transparent first as a PNG, then compress to WebP, and the alpha survives the trip.
Why does my WebP transparent background show as black or white?
Most of the time the transparency did not break; the program showing the file just cannot render alpha. When a WebP transparent background suddenly appears as a black or white box, the usual cause is an old image viewer, a chat app, or an editor that reads WebP color but ignores its alpha channel and fills the see-through area with a default fill.
The viewer, not the file
Before assuming the alpha channel is gone, open the same file in a current web browser, which renders WebP transparency correctly. If the background is transparent there, the file is fine and the earlier program was the problem. This is the single most common false alarm with transparent WebP, and it sends people re-exporting a file that was never broken.
When the transparency really is gone
The transparency is genuinely lost only if the file passed through a step that cannot hold alpha. The classic one is a conversion to JPEG somewhere in the chain, which permanently replaces transparent pixels with a solid fill. A flatten-on-export setting in an editor does the same. If a browser also shows the background filled, retrace the steps: something converted to JPEG or flattened the layers, and the fix is to go back to the transparent source and re-export straight to WebP or PNG without the JPEG hop in between.
What are the disadvantages of WebP for transparent images?
The honest downsides are older-software support and one quality edge case, not the transparency itself. WebP's alpha is as capable as PNG's; the friction is everything around the file, not the file's transparency.
Support is the main one. Every current browser reads transparent WebP, but some desktop viewers, older office software, and a few chat and design tools still do not, which is why a WebP can look broken in one program and perfect in another. Browser support today is effectively universal on current versions (Can I use WebP), so the gap is desktop apps and old builds, not the modern web.
| Where you open it | Transparent WebP support |
|---|---|
| Current web browsers | Full, renders alpha correctly |
| Recent macOS and Windows | Reads WebP in the OS image viewers |
| Old desktop viewers and editors | Often no alpha, shows a black or white fill |
| Design and chat apps | Mixed, check before you rely on it |
The second downside is the lossy edge case already covered: pushed hard, lossy WebP can slightly soften a razor-sharp alpha boundary, so a crisp icon is safer in lossless mode. Neither of these is a reason to avoid transparent WebP on the web, where it is smaller than PNG and reads everywhere. They are reasons to keep a PNG copy for the odd tool that has not caught up, and to sanity-check a hard-edged graphic before shipping it at the most aggressive quality.
Frequently asked questions about WebP transparency
Does WebP support transparency like PNG does?
Yes, in both of its modes, not just one. Lossless WebP carries full RGBA alpha for about 22 percent more bytes than the same image without transparency, and lossy WebP carries a separate alpha plane for typically about a third the size of an equivalent PNG. The alpha depth is 8-bit in both formats, so WebP matches PNG's transparency precision exactly and stores it in fewer bytes.
Is lossless or lossy WebP better for a transparent logo?
Lossy, if the logo has soft edges, gradients, or photographic elements, because it wins on size by a wide margin with no visible edge cost. Lossless, if the graphic is flat color with hard edges like a wordmark or a simple icon, where aggressive lossy compression can occasionally soften a crisp boundary. Test both on the real file, since the size difference is large enough to be worth the quick comparison.
Does converting a transparent WebP to JPEG keep any transparency?
No, none of it. JPEG has no alpha channel, so it cannot store transparency in any form, and every transparent pixel gets replaced with a solid fill color during the conversion. Convert to PNG instead when the file needs to leave WebP and keep its transparency; convert to JPEG only once you genuinely no longer need the alpha channel at all.
Does animated WebP support transparency?
Yes. Animated WebP uses 24-bit RGB color with an 8-bit alpha channel, the same alpha depth as still WebP, so frames can be fully transparent, fully opaque, or anywhere between, frame by frame. That combination of real animation plus real alpha is something GIF has never managed, and it is covered in full on the animated WebP guide.
Why does my transparent WebP look like it lost its background?
Usually the file is fine and the program showing it cannot render WebP alpha, filling the transparent area with black or white instead. Open the same file in a current web browser to check: if the background is transparent there, an older viewer was the culprit. If the browser also shows a fill, the transparency was lost in an earlier JPEG conversion or a flatten step, and you need to re-export from the transparent source.
Both WebP modes carry real transparency, not a watered-down version, and the lossy mode's byte savings over PNG hold with a full alpha channel attached. When you want the actual number on your own graphic, run a transparent PNG or WebP through the compressor here and read the byte count with the alpha channel still intact.