The logo you need is a .webp, and the tool that needs it isn't

It always surfaces on deadline day. The brand guidelines live on a site you don't control, the logo you need is right there on the page, you right-click and save — and what lands in your downloads folder is logo-mark.webp, complete with the transparent background you specifically needed. Then the vendor portal, the old Photoshop install, the presentation template, whatever 2016-era system is waiting on the other end, looks at that extension and offers you its most polite error message.

The frustration is structural, and we'd argue it's even a little funny: the web gave you the modern, efficient, transparency-capable file, and your destination wants the older, heavier, equally transparency-capable one. PNG and WebP can express the exact same pixels with the exact same alpha. One of them just does it in half the bytes, which is precisely why the site served it — and precisely why nothing downstream understands it.

This converter is the bridge, and the direction matters: WebP in, PNG out, alpha fully intact. Lossless encode, live checkerboard preview so you can verify the transparency yourself before downloading, batch support for the days when it's forty icons instead of one logo. It runs entirely in your browser — the files never leave your machine — and there's no quota, watermark, or signup anywhere in the pipeline. The rest of this page explains what happens under the hood, why the output file grows (it will, and that's correct), and how to check the one place where WebP-to-PNG conversions can misbehave: the edges.

Why PNG is the right exit ramp

When software won't read WebP, you have two possible destinations, and they're not interchangeable. PNG is the lossless one. It stores every channel — red, green, blue, and alpha — at full precision, with no quality slider and no settings to get wrong. What goes in comes out. It's also thirty years old this decade, which is the entire point: any image software written after the mid-nineties can open it, and so can every printer, browser, kiosk, and portal.

PNG's transparency is full 8-bit alpha, the same model WebP uses, which is what makes this conversion clean. Your logo's anti-aliased edges, soft drop shadows, and semi-transparent gradients all express themselves naturally — 0 for fully clear, 255 for fully opaque, and 254 honest steps of blend between. No dithering tricks, no binary cut-outs, no color-keying like the GIF era demanded.

That alpha model earned its ubiquity the hard way. Before PNG, transparency on the web meant GIF — one bit of it, on or off, with every soft edge reduced to jagged stairs or fake dithering. PNG arrived in 1996 and quietly fixed the entire problem with an eight-bit channel, and thirty years of software has been built on that promise since. When you need a file that every tool in a long chain will interpret identically, you're not choosing PNG out of nostalgia. You're choosing the oldest, most boring, most universally honored contract in digital imaging.

The price is size, and it's worth naming plainly because the tool will show it to you: PNG is a less efficient container than WebP for most content, so your output will usually be larger than your input — sometimes dramatically so on photographs. That's not a defect in the conversion; it's the cost of leaving the efficient format for the universal one. You're buying compatibility with bytes, and the exchange rate is published below with real numbers.

There's a mindset shift worth making about file growth, because not every conversion is a delivery decision. Web pages want small files; archives and editing pipelines want honest ones. A folder of lossless WebPs is an efficient place to keep pixels, but it's a format only modern decoders can cash. The same pixels as PNG can be opened by anything, edited by anything, scripted by anything, and handed to a service from 2009 without a support ticket.

Storage is the cheapest component in any modern workflow, and compatibility failures are among the most expensive. The +46% you pay converting a lossless WebP screenshot back to PNG isn't a loss — it's an insurance premium against the day the WebP can't be read where the PNG would have been. Keep the efficient format for transit, keep the universal format for anything that outlives a specific project, and use this converter as the valve between the two reservoirs.

Converting, step by step

  1. Drop in the WebP files

    Drag one file or a hundred from your downloads folder. The queue shows each file with its incoming size, so you have a baseline before anything happens.

  2. Let it decode

    Each WebP unpacks instantly — lossy files through VP8 reconstruction, lossless through the VP8L transforms, and any alpha channel comes along for the ride automatically.

  3. Verify transparency on the checkerboard

    The preview sits on a checkerboard background by default. If the source had transparency, you see it here immediately: same cut-out shape, same soft edges, nothing filled in with white.

  4. Zoom the edges

    Push the preview to 400% and look where color meets transparency. A clean conversion shows smooth anti-aliasing. Any fringe or halo came from the source's original lossy encode, not the conversion — PNG preserves what the WebP contains.

  5. Check the output size

    The size column shows the PNG result against the WebP input. Growth is expected; this is where you confirm the growth is reasonable rather than accidental.

  6. Download

    One file or the whole batch. Filenames keep their stems; extensions become .png. Transparent files come out as PNG-32 — full RGBA, ready for any editor.

Under the hood: unpacking one container, packing another

The first half of the job is decoding. The browser's native WebP decoder reads the RIFF container, finds the frame — VP8 for lossy, VP8L for lossless — and reconstructs it into a plain RGBA bitmap in memory. If the file carries an ALPH chunk, the separate plane where lossy WebP keeps its transparency, that decodes too and merges back into the bitmap's alpha channel. At this instant the image is no longer WebP in any meaningful sense. It's just pixels.

The second half is writing PNG, and PNG's encoder has a genuinely elegant trick at its core. Before compression, every scanline passes through one of five filters — None, Sub, Up, Average, or Paeth — which transform each pixel into a small residual against its left neighbor, its upper neighbor, or a blend. The encoder picks whichever filter makes the row's values smallest, because small values compress beautifully. The filtered bytes then go into DEFLATE, the same LZ77-plus-Huffman machinery gzip uses, and out comes the .png you'll download.

A one-line example makes the filter trick concrete. A row of near-identical blue pixels — 40 90 200, 40 91 200, 40 91 201 — stores poorly as raw bytes, because every value is large. Apply the Sub filter, which keeps each byte and subtracts its left neighbor, and the row becomes 40 90 200, 0 1 0, 0 0 1. Same information, three large numbers followed by a run of almost-nothing — and DEFLATE compresses almost-nothing down to nearly free. That is PNG's whole strategy, executed per row, with the encoder free to switch filters whenever the image's texture changes.

Understanding that pipeline explains the size behavior precisely. DEFLATE works on byte patterns; VP8L works on pixels with spatial prediction, cross-color transforms, and a color cache. The pixel-aware codec wins on almost everything, which is why your PNG will be bigger than the WebP was — roughly 25–100% bigger on graphics, and often 4–6× bigger on photographs, where PNG's losslessness is wasted on content that doesn't need it. If the destination accepts JPG and your image is a photograph, the WebP to JPG Converter is the cheaper exit. PNG is for the files where fidelity or alpha is the point.

Three files, measured honestly

Here's what the size tax looks like on real files — one transparent logo, one lossless screenshot, one photograph, all converted with this tool:

FileWebP inPNG outGrowthNotes
Logo, 800×800, alpha, lossy q9042 KB156 KB+271%Alpha identical; edges clean at 400%
UI screenshot, 1920×1080, lossless0.81 MB1.18 MB+46%Pixels bit-exact — full restoration
Photo, 1,600×900, lossy198 KB1.02 MB+415%Correct pixels, wrong format — use JPG for photos
The compatibility tax, itemized. Graphics pay modestly; photographs pay dearly.

The screenshot row deserves a spotlight. That file went PNG → lossless WebP → PNG, and it came home: 1.18 MB in, 0.81 MB while it lived as WebP, 1.18 MB out, with identical pixels at every step. Lossless WebP is a legitimately good archival compression for that kind of content, and this converter is what lets you cash it back out whenever the pixels need to be somewhere that only speaks PNG.

Worked example — the deadline-day logo

Input

logo-mark.webp — 800×800, lossy with alpha, 42 KB

Output

logo-mark.png — 800×800, PNG-32 with full alpha, 156 KB — opens in the 2016-era portal, transparency intact

One hundred and fourteen kilobytes bought that logo entry into every piece of software still running on Earth. Measured against the alternative — re-creating the cut-out by hand, or explaining to a client why their own brand page broke your workflow — it's the cheapest fix available all week.

Alpha, edge to edge: the one thing to inspect

Transparency conversions have a single failure mode worth knowing about, and it lives on the boundary between opaque and transparent pixels. When a WebP was encoded lossily, the color channels near that boundary were quantized like any other color — slightly shifted, slightly softened. The alpha channel stayed sharp, but the colors it reveals at the edge can carry the fingerprints of that compression. On a hard-edged logo this is invisible. On a soft-edged cut-out against a very different background, you can occasionally see a one-pixel fringe of the wrong hue.

The important framing: this fringe was baked in when the WebP was created, not during this conversion. PNG is faithfully reporting damage that already existed. If a fringe bothers you, the real fix is upstream — get the original lossless asset, or route through the source design file. What you can verify here is that nothing new went wrong: zoom to 400%, walk the edge, confirm it matches what the WebP showed in your browser before you converted it. Identical is the goal, and identical is what a clean conversion delivers.

A subtler rounding note for the pixel-obsessed: canvases store semi-transparent pixels in premultiplied form internally — color values pre-multiplied by their own alpha for faster compositing — and un-premultiply them when writing output. On nearly-transparent pixels (alpha of 1 or 2 out of 255) the round trip can shift a color value by a single step. It's invisible at any zoom and irrelevant to every practical purpose, but if you ever diff two files byte-wise and find a couple of changed values on ghost-faint pixels, that's the mechanism, not a bug.

Cases that behave differently than you'd guess

  • Animated WebP yields frame one. The sequence decodes as a single still — the first frame — and the rest is gone. Looping stickers and animated buttons need a frame-export tool, not a still converter.
  • Lossless sources are the happy path. A VP8L WebP decodes bit-exact, so the PNG is a perfect restoration. If you're rescuing screenshots or exported graphics that were stored losslessly, everything you're copying is intact.
  • Huge inputs hit memory first. A 12,000×9,000 image is 432 MB of RGBA in RAM before the PNG encoder even starts, and PNG encoding wants scratch space on top. Very large files work on desktops, slowly, and fail politely on phones.
  • Color profiles don't survive. The canvas pipeline assumes sRGB and writes no ICC profile into the output. Web for-work, print from-work: if the destination is print, color-manage in a proper editor afterward.
  • A PNG that grew absurdly usually means photographic input. That +415% row in the table above isn't an anomaly — it's PNG correctly refusing to be something it isn't. Photographs belong in lossy formats; convert them to JPG unless the destination demands otherwise.
  • The .webp extension occasionally lies. Some files wear the extension and contain something else — usually a JPEG or PNG that a lazy pipeline renamed. The decoder reads the actual bytes, not the suffix, so mislabeled files usually just... convert, and the confusing part is explaining why it worked.

Who needs this direction specifically

Designers and art workers, mostly, and the subset of them maintaining assets for older systems. The brand-asset-from-a-website scenario is the canonical one, but it has cousins: icon sets distributed as WebP that need to live in a tool whose plugin never shipped, texture work for game mods where the engine wants PNG input, documentation images that must be editable in whatever the client has licensed. In every case the job is the same — recover the pixels and the transparency into the format everything already reads.

  • Designers pulling brand assets from sites that only serve WebP, into tools from before WebP's mainstream era
  • Icon and asset maintainers re-cutting libraries for engines and apps with PNG-only pipelines
  • Game modders converting texture packs between formats the engine and the sources disagree on
  • Documentation teams rescuing screenshots archived as lossless WebP into editable, annotatable PNGs
  • Print and signage shops accepting customer files that arrive as WebP from web-sourced everything
  • Developers debugging — opening a WebP that renders strangely by converting it to PNG and inspecting the actual pixel values

That last one is more common than you'd expect. When a served image looks wrong and you suspect the file rather than the CSS, converting to PNG and clicking through the pixels is the fastest diagnosis there is — no color management, no renderer opinions, just the truth of what the decoder produced.

Two exits, one decision

Everything above reduces to a single choice, and it's the same one from the JPG direction with the stakes reversed:

Your WebP contains...Best exitWhy
Transparency you need to keepPNGJPG has no alpha; PNG carries it losslessly
Text, line art, screenshotsPNGLossless output preserves hard edges exactly
Photographs, no transparencyJPGA quarter of the size, no visible cost at q88+
Something you'll re-edit or re-exportPNGEditing masters should be lossless
Something headed straight into an old uploaderEither — check the whitelistBoth formats predate the problem by decades
Fidelity or size. With transparency in play, fidelity wins by default.

When the day's work flows the other way — shrinking a PNG library into efficient WebP for delivery — the PNG to WebP Converter is this page's mirror image, lossless mode included. And for the JPEG-family needs, the JPG to PNG Converter covers sources that start life as photographs.

The pixels stay on your side of the wire

This converter has no upload stage. That's not marketing phrasing — there is genuinely no code path by which your image data leaves the page. Files enter through the browser's local file interface, the WebP decoder unpacks them in memory, the PNG encoder packs them back up, and the download lands wherever your browser puts downloads. The network connection could be severed between those steps and nothing would change.

For the people this tool serves most — designers handling client brand assets, anyone moving proprietary graphics, the cautious — that architecture answers the security question before it's asked. There is no copy of your logo on anyone's server, because it was never on a server. There is no retention policy to read, because there is nothing to retain. Local execution is the privacy policy.

Questions from the transparent-background crowd

Does converting WebP to PNG lose quality?

No. The PNG encode is lossless — every pixel that comes out of the WebP decoder goes into the PNG exactly. The quality ceiling is set by your source: a lossy WebP already carries compression artifacts, and PNG will preserve those artifacts faithfully rather than heal them. A lossless WebP round-trips to identical pixels.

Will the transparent background stay transparent?

Yes. WebP's alpha channel decodes completely, and PNG stores alpha as a full 8-bit channel — the formats are well matched here. Toggle the preview's checkerboard and you'll see the same cut-out, same edges, same soft shadows as the original.

Why is my PNG so much bigger than the WebP was?

Because you traded compression efficiency for compatibility, and that trade has a price. PNG's DEFLATE-based pipeline typically needs 25–100% more bytes than WebP for the same pixels, and several times more on photographs. The tool isn't inflating anything — it's showing you what the pixels actually cost in the older format.

Can this convert animated WebP files to PNG?

Only the first frame survives — the canvas decode path extracts a single still image, which is frame one of the sequence. If you need every frame of an animation, you want a frame-export tool built for sequences, not a still-image converter.

What if my editor accepts WebP anyway?

Then don't convert — modern Photoshop, Affinity, and current browsers all handle it natively. This tool is for the long tail: older Photoshop installs, vendor portals, print intake systems, and internal tools whose format whitelists were written before WebP existed.

Does it handle lossless WebP differently?

Same interface, better outcome. A lossless WebP decodes to bit-exact pixels, so your PNG is a perfect restoration rather than a re-save. If you know the source is lossless — screenshots from developer docs usually are — you can convert with total confidence.

Is there a batch limit?

Only your hardware. The queue decodes each image into RAM at four bytes per pixel, so memory is the boundary — hundreds of typical web graphics on a laptop, dozens on a phone. No server quota exists because no server is involved.

Is it free, and does it upload my files?

Free, no signup, no watermark, no metered conversions — and nothing uploads. Decoding and encoding run in your browser's canvas; the files stay on your machine from start to finish.

Sources and further reading

Sources and further reading

We cite primary sources (standards bodies, government agencies, official documentation) wherever they exist so you can verify every number on this page yourself.