Convert PNG to WebP

PNG to WebP is really two conversions sharing one name

A WebP file can be built two entirely different ways. The lossless form, VP8L, reproduces every pixel exactly. The lossy form, VP8, discards information the encoder judges you will not notice. They share a file extension and nothing else, and picking between them is the only decision on this page that really matters — so it is a visible control rather than a default someone chose on your behalf.

Here is why no default can be right. Two of this tool's own test files, converted both ways: a 480 by 270 transparent badge started at 1,908 bytes and came back at 1,506 bytes losslessly but 3,176 bytes at quality 80 — smaller when nothing was thrown away, larger when something was. A 480 by 360 photograph started at 325,000 bytes and came back at 210,380 losslessly and 16,834 at quality 80. Identical settings, opposite winners, and the difference is not the settings but the subject. Flat regions and hard edges want exactness; continuous tone wants approximation. A tool that picks for you is wrong roughly half the time, which is why this one measures both and shows the pair of numbers before you commit.

How this page knows the lossless mode is genuinely lossless

There is no browser API for "encode WebP without loss". There is only a quality number, and each browser has its own private rule about which value flips the encoder into VP8L. In Chromium, measured rather than looked up, that value is exactly 1.0 — below it you get VP8. No specification promises this, and no other engine is bound by it.

So the tool checks instead of trusting. Before any of your files are touched it encodes a 64 by 64 square of random noise at quality 1, decodes the result, and compares every single byte against what went in. Noise, not a flat swatch, because a flat swatch survives even brutal lossy compression and the check would pass on any encoder alive. If a single byte differs, the mode is not offered at all and the page says so. A button labeled Lossless that quietly produces VP8 would be worse than having no button, since you would have no way to tell from the file you downloaded.

Indexed PNGs are the case that catches people out

Some PNGs store a table of up to 256 colors and then reference it, rather than storing full color values per pixel. Export a chart, a diagram or a logo from most design software and this is often what you receive. These files are already extraordinarily compact, and they are the ones that come back larger.

The mechanism is worth understanding because it is not really about WebP. A browser decodes any image to full-color pixels before an encoder can touch it, and the color table is discarded at that step. Whatever encodes next never sees the compact form you started with — it sees an ordinary full-color picture and compresses it as one. Measured here: a 800 by 500 chart of 4,938 bytes became 19,590 bytes losslessly. Four times the size, no pixels changed, and the same thing happens whichever format you convert it to.

That is why the tool reads the IHDR color type out of every PNG you drop and flags the indexed ones by name and palette size before you choose anything. When you see that flag, check the estimate and be prepared for the answer to be "keep what you have". For files where the goal is a specific size rather than a specific format,compressing to a target size attacks the problem directly.

Alpha survives, animation does not

Transparency comes through untouched in both modes, which is a genuine advantage WebP holds over JPEG and the reason converting a transparent image this way is reasonable at all. Animation is the opposite story. WebP is perfectly capable of holding one, but no browser writes an animated WebP from a canvas — so an APNG dropped here is detected from its acTL chunk, the frame count is reported, and only the first frame is encoded. The limitation belongs to the encoding path, not to the destination format, and it is worth being precise about that rather than blaming WebP for something it can do.

Convert what you serve, keep what you send

Browser support stopped being the interesting question years ago; every browser in current use reads WebP. What has not caught up is everything that is not a browser. Plenty of email clients, older desktop applications, print workflows and third-party upload forms still refuse the format outright, and a picture nobody can open is not an optimization.

The practical rule is to convert images that a web page will serve and keep the originals for anything that gets attached, printed, or handed to another system. And if you are on the receiving end of that problem — a downloaded .webp that your software will not touch — the conversion runs the other way at WebP to PNG.

Everything on this page runs on your own hardware. Your browser decodes PNG because it has to, and its WebP encoder is the same one that answers the probe described above, so the pictures never travel anywhere. What that costs you is metadata: encoders here are handed pixels only, so color profiles and any embedded text do not survive the conversion.