Convert WebP to PNG online, free

How transparency survives the conversion

Transparency in a WebP is stored as an alpha value attached to each pixel. A pixel can be fully opaque, fully transparent, or anywhere in between. That in-between range is what gives you soft drop shadows, anti-aliased curves, and glows that fade to nothing.

The conversion redraws the decoded WebP onto an HTML Canvas, which preserves the per-pixel alpha, then asks the browser to encode that canvas as a PNG. The PNG specification supports the same full 8-bit alpha range, so the values map across one to one. A pixel that was 40 percent opaque in the WebP stays 40 percent opaque in the PNG.

This matters most at the edges. A cheap conversion that flattens transparency leaves a faint halo or a hard fringe where the soft edge used to be. Because the alpha is kept rather than collapsed onto a background, the edges stay clean and the asset drops onto any color underneath without a visible seam.

After a conversion, open the Compare view on a file and slide over the transparent region to confirm it reads as you expect. It is a five-second check that saves you from importing a flawed asset into a design file.

PNG files are usually bigger, and that is fine

Here is the honest part. The PNG you get back will almost always be larger than the WebP you started with, often two to four times the size on photographic content. That is not a fault in the conversion. It is the expected result of moving from a heavily compressed format to a lossless one.

WebP was built to squeeze photos down hard, using lossy compression that discards data your eye is unlikely to miss. PNG does the opposite. It records every pixel exactly and leans on lossless compression, which works well for flat color and sharp edges but cannot match WebP on the busy detail of a photograph. The bytes have to go somewhere, so the file grows.

You are paying that size premium on purpose, in exchange for transparency, lossless pixels, and a format that opens everywhere. When the destination is an editor, a design file, or a build pipeline, the larger file is the correct trade. When the destination is the open web, it usually is not, and you have two cleaner paths described below.

If a converted PNG is destined for hosting, compress the PNG output afterward. Its oxipng pass often removes 20 to 40 percent of the size with no change to the pixels. If transparency does not matter at all, the WebP to JPG tool will produce a far smaller file than either.

What lossless conversion can and cannot recover

The word lossless describes the conversion step, not the history of the file. It promises that nothing is lost going from WebP to PNG. It says nothing about what was already lost before the WebP reached you.

WebP comes in two flavors. A lossless WebP holds its original pixels exactly, and converting that to PNG gives you a perfect copy of those pixels in a new wrapper. A lossy WebP was compressed with detail already thrown away, and that loss is permanent. Converting it to PNG stores the current, already-degraded pixels faithfully, but it cannot rebuild detail that the lossy encoder removed.

So a lossy WebP that shows soft blocking around text or banding in a sky will carry those same artifacts into the PNG. The PNG will look identical to the WebP, not better. People sometimes expect a jump to a lossless format to clean up a rough source, and it will not. The only way to a clean PNG is a clean source.

The practical takeaway: convert from the best WebP you have, not from a copy that has already been through several rounds of compression. If you control the original asset, start there.

Getting WebP into editors and software that reject it

PNG is the common tongue for transparent images. Decades of tools read and write it without a second thought, which is exactly why converting to it solves so many compatibility headaches.

Older versions of Photoshop will not open a WebP without an added plugin, while every version opens PNG directly. Even though WebP support is now near universal in browsers, the same gap still shows up across the stack: some design tools, many operating system preview and thumbnail features, presentation apps like PowerPoint and Keynote, and a fair number of content management systems either fail on WebP or render it inconsistently. Hand them a PNG and the problem disappears.

This is the workflow most people land here for. You receive a transparent graphic as a WebP, the program you need to use it in refuses the file, and you need a version it accepts within the next minute. Drop the WebP, download the PNG, carry on. The transparency is intact and the pixels are unchanged, so the asset behaves exactly as the original was meant to.

The same move covers preparing an asset for an operating system or device that expects PNG, or feeding a graphic into a script or pipeline that only knows how to read PNG input.

Building icon and sprite assets from WebP

Icons, logos, and small UI marks are some of the most common things people convert to PNG, and for good reason. They almost always carry transparency, they get reused across many tools, and most of those tools want PNG.

A logo distributed as WebP for fast web delivery often needs to become PNG before it can enter an app build, a favicon generator, or a platform-specific icon tool. Each of those toolchains tends to assume PNG input. Converting once gives you a clean, lossless PNG source you can feed into all of them rather than fighting the format at every step. When the web version is what you are missing, you can also make WebP from PNG to go the other way.

Sprite work follows the same pattern. If you are pulling individual graphics out of a set, or assembling several transparent pieces into one sheet, PNG is the format that keeps each element editable and keeps the transparency between them honest. There is no background color bleeding into the gaps.

Because the conversion runs in a batch, you can drop a whole folder of icon WebPs at once and get back a matching set of PNGs with the original names and a new extension. That keeps your asset naming consistent, which matters when a build script is looking for files by name.

A quick workflow that keeps files manageable

Start by deciding what the PNG is for. If it is going into an editor or a build, convert and move on; the size does not matter much for a working file. If it is going on the web, plan a second step before you ship it.

When the source WebP is far larger than the size you will display the image at, resize it before converting. A 4000-pixel-wide WebP that you only show at 800 pixels will produce a needlessly heavy PNG. Trim it down first and the PNG comes out smaller while keeping all of its transparency.

Use the batch capacity rather than converting files one at a time. Up to 100 WebP files, each as large as 50 MB, can go in together, and they all decode and re-encode locally before arriving as a single ZIP. For a folder of icons or a set of marketing graphics, that turns a long manual chore into one drop.

Everything here happens on your device. The WebP you drop and the PNG you download both stay in the browser, with no server in the loop, no account, and no ads. That is what makes it safe to run client logos, unreleased designs, or any private asset through the converter without a second thought.