PNG to WebP Converter

Somewhere on your drive sits a folder called assets-final, or assets-final-v3 if you're being honest about it. Forty PNGs. The logo at 148 KB. The three button states, the hero illustration, the twelve UI screenshots for the docs page. Individually none of them is a problem. Together they're 4.6 MB of graphics, most of it air — PNG paying full freight for pixels that a smarter codec could describe for a fraction of the bytes.

We kept paying that freight because PNG had one thing JPEG never did: an alpha channel. Transparency was non-negotiable for anything that sat on a colored background, so lossless-and-heavy beat small-and-rectangular, and that was the end of the discussion. WebP ended the trade-off. It carries alpha too — lossy or lossless — and its lossless mode runs about 26% smaller than PNG on Google's published corpus. Same crisp edges, same transparency, three-quarters of the weight.

The converter on this page takes PNGs in and hands WebPs back, with a mode switch for lossless and a quality slider for lossy, plus a live preview so you can see exactly what each setting costs you. Nothing uploads. Nothing gets watermarked. There's no free-tier counter ticking down, which matters if you've already burned through a month of credits on a subscription converter. The rest of this article explains which mode to pick, what happens inside the file, and where the corner cases live — because PNG work has corner cases the way old houses have basements.

The first thing to understand about WebP is that it's really two codecs sharing a file extension. Lossy WebP is VP8 keyframe coding — a video codec's intra-frame machinery applied to stills, the same path the JPG to WebP Converter uses for photographs. Lossless WebP is VP8L, an entirely separate compressor designed from scratch for graphics where every pixel must survive intact. They share a container and a decoder API and almost nothing else.

That distinction drives every decision you'll make here. Photographs and soft-edged illustrations tolerate lossy coding beautifully — that's what the format's quality slider is for. Text, screenshots, line art, and anything with hard pixel edges do not; JPEG-style artifacts around glyphs look terrible, and VP8L exists precisely so you never have to accept them. Pick the mode by content, not by habit:

The savings column is honest but not a contract. VP8L sometimes loses to a PNG that's already been through an aggressive optimizer, and tiny files under a couple hundred bytes can go either way. Folders, not files, are where the pattern holds.

1. 1

   Drop in your PNGs

   Single files, multi-selects, or whole folders — the queue accepts them all and shows each file's current size up front.

2. 2

   Choose the mode

   Lossless for screenshots, text, and line art; lossy for photographic or soft content. The switch sits next to the quality slider and re-encodes the preview instantly.

3. 3

   Set the quality slider (lossy only)

   Start at 90 when transparency is involved — edges between color and alpha deserve the headroom. Drop toward 75 for purely photographic material.

4. 4

   Check transparency and edges

   Toggle the preview's checkerboard background and zoom to 400% on the boundary where color meets transparent. Halos or dark fringes mean lossy is being too aggressive; bump quality or go lossless.

5. 5

   Read the savings column

   Each file shows before, after, and the percentage saved. Anything that went the wrong direction — it happens on small files — you'll spot immediately and keep the original.

6. 6

   Download

   Individual files or the whole batch in one click. Names keep their stems; extensions become .webp.

To see why one codec beats another at the same job, you have to watch where each one spends its cleverness. PNG's pipeline is from 1996: every scanline of the image is passed through a filter — None, Sub, Up, Average, or Paeth — chosen per row to turn neighboring pixels into small residuals. Those residuals then go into DEFLATE, the same LZ77-plus-Huffman compressor that gzip uses, with a 32-kilobyte sliding window and no knowledge that it's looking at an image.

It works. It's also leaving money on the table in two places. The filters only look along one dimension at a time, and DEFLATE matches byte strings rather than reasoning about color. VP8L attacks both weaknesses, and a handful more:

• Per-pixel spatial prediction. Fourteen predictor modes — left, top, top-right, diagonal averages, and two clamped mixtures that estimate the current pixel from its three nearest reconstructed neighbors. Blocks choose their own mode, so a diagonal roofline and a flat sky use different math in the same image.
• A cross-color transform. Green usually predicts red and blue tolerably well, so VP8L decorrelates the channels against green with small transmitted multipliers before entropy coding, concentrating the information where it actually is.
• A color cache. A small hash table of recently coded colors lets the encoder emit a short cache index instead of full channel values every time a color repeats — which, in UI screenshots, is constantly.
• A palette transform. Images with few distinct colors collapse to palette indices, with deltas between neighboring palette entries coded instead of the entries themselves.
• Backward references. LZ77-style copying of pixel runs, the one trick PNG has too — but VP8L's distances can reach across the whole image rather than DEFLATE's 32 KB window, and the code lengths adapt per color plane.

There's also a subtract-green step that sounds trivial and pays for itself embarrassingly often. In UI graphics, red and blue values tend to sit close to green — a button is one hue at three brightnesses, not three independent colors. Subtracting green from red and blue before coding turns three correlated channels into one meaningful channel plus two small residuals, and small residuals are what entropy coders eat for breakfast. On a flat-color icon, that single transform routinely moves the needle by double-digit percentages.

Every residual and index then goes through prefix coding with separate code tables for each channel plus distances, so the statistics of green don't contaminate the statistics of red. Stack those gains and the measured result across Google's test corpus is roughly 26% smaller than PNG for the same pixels. Your mileage is content-dependent — flat-color graphics with repeated elements gain the most, noisy photographs the least, and photographs belong in lossy mode anyway.

Transparency is the reason most PNGs exist, so it deserves its own conversation. In your source file, alpha is a full 8-bit channel: 0 for fully transparent, 255 for fully opaque, and 254 steps of blend in between. Any conversion path that mangles that channel turns a clean cut-out into a fringed mess, and this is where old JPEG-era habits get people into trouble.

In lossless mode there's nothing to discuss — alpha is coded like any other channel and reconstructed exactly. In lossy mode, WebP does something quietly brilliant: the RGB channels get the lossy treatment, but alpha travels in a separate plane compressed with the lossless machinery. Your color gets smaller; your shape stays pixel-perfect. The one failure mode is perceptual rather than structural — lossy color quantization near a transparent edge can shift the pixels that are 90% transparent, leaving a faint halo where the old color used to be. Quality 90 or above keeps this invisible in almost every case, and the preview's checkerboard toggle exists so you can confirm it yourself.

Compare that with the PNG-only alternative workflow people still use: flatten to a solid background color to get JPEG's smaller files, then hand-match that background on the destination page. It works until the destination changes its theme, at which point every image shows a rectangle of 2019-era off-white. Baked transparency plus a modern format is simply the correct architecture, and now it's also the smaller one.

One subtlety for people building rendering pipelines rather than just shipping files: compositing math treats semi-transparent pixels as weighted blends, so an artifact in a mostly-transparent pixel contributes almost nothing to the final image. That's why lossy color coding near alpha edges is safer than it sounds — the damaged samples sit at low opacity where nobody can see them. The visible failures are confined to the hard boundary itself, which is exactly the strip the preview asks you to zoom into. Soft gradients that fade to nothing, like glows and shadows, are effectively immune; they're mostly air by volume.

Theory is cheap, so here are three graphics from an ordinary project folder, converted with this tool on default settings:

The logo story is the interesting one. Lossless takes a modest quarter off, but lossy at q90 takes three-quarters off — and on a flat-color logo with a soft shadow, the difference is invisible at any zoom a human uses. That's the 114 KB you keep paying for the privilege of not having looked closely. Check the shadow's gradient banding at 400%; if it's clean, ship the 34 KB file.

Now scale that across the asset folder from the top of this article. Forty files at 4.6 MB, mixed content, each converted in its proper mode: the folder lands near 2.9 MB. No design changes, no resolution changes, one afternoon of drag-and-drop. On a docs page that loads five screenshots per article, the lossless mode alone cuts the image weight of every visit by about a third, forever.

PNG has been the working format for so long that its quirks feel like features. Convert enough of them and you meet every one:

• APNG drops its animation. Animated PNGs decode to their first frame in the canvas pipeline, so the output WebP is a still. If you need motion, convert to an animated WebP or a video file at a tool built for sequences — this one is for stills.
• 16-bit PNGs come down to 8. Browsers decode deep-color PNGs into 8-bit-per-channel buffers before the canvas sees them. For microscopy, astronomy, and HDR source material, the extra precision does not survive the trip; keep originals for anything scientific.
• Indexed PNGs unroll. Palette-based PNG-8 files get expanded to full color during decode. VP8L usually re-palettes them internally, so the size penalty is small, but a 4 KB icon can occasionally round-trip slightly larger.
• ICC profiles vanish. Canvas re-encoding assumes sRGB and writes no profile chunk. If your PNGs were tagged for a print workspace, convert them in a color-managed editor first — this pipeline is built for screens.
• Alpha edges deserve one manual look. Everything above says lossy alpha is safe at q90. Almost everything is. Zoom into one edge per batch anyway, because one misbehaving gradient in a thousand files is still one customer-visible halo.
• 16383 pixels per side is the ceiling. The codec's hard limit, and your RAM usually taps out first — a 16000×16000 RGBA buffer is a full gigabyte before encoding even begins.

Front-end teams ship design systems, and design systems are mostly small transparent PNGs by the hundred. Converting an icon set to WebP is a one-afternoon chore that pays out on every page load for the life of the product — and it's the kind of chore that never quite justifies a CI pipeline on small teams, which is exactly why a browser tab beats a build step here.

Documentation writers are the other quiet bulk users. Every product docs site carries hundreds of screenshots, and screenshots are the content type where lossless WebP's 30% is closest to free money — text stays razor-sharp and the files shrink by a third. Technical writers rarely have an image pipeline at all; they have a folder and a deadline.

• Web designers delivering final assets, who hand the client a folder that weighs a quarter of what it used to
• Icon library maintainers, re-cutting entire sets when a format shift lands
• Indie game and web-app developers, whose UI texture atlases live as transparent PNGs until the day they shouldn't
• Marketers cleaning up landing pages before a speed audit, where the logo is somehow always the largest remaining image
• Anyone who just hit a converter site's free limit at file number four and would rather not enter a credit card to do work their own CPU can do for nothing

Strip away the history and you're choosing between three containers for the same visual job. Here's the decision as a single picture, using the logo from our test folder:

The reason PNG still wins any column at all is reach: if your audience includes devices from before 2020 or unusual embedded browsers, PNG is the format that cannot fail. Everywhere else, lossless WebP dominates it on size at identical fidelity, and lossy WebP dominates it dramatically once the content tolerates quantization. When you need the reverse trip — a WebP that some old editor refuses to open — the WebP to PNG Converter makes the round journey. And when a hard kilobyte cap matters more than the format, the Image Compressor targets a number instead of a container.

Every stage of this converter — decode, preview, encode, download packaging — runs as JavaScript inside your browser. The PNG never travels to a server, because there is no server stage in the pipeline to travel to. Files come off your disk through the standard file API, get decoded into a canvas buffer, re-encoded by the browser's built-in WebP encoder, and written back out as a download. The network stays silent throughout.

This isn't just a privacy posture; it's why there's no metered free tier. Cloud conversion services pay for upload bandwidth, queue infrastructure, and CPU time on rented machines, so they meter you — five files, ten files, twenty conversions a day, then a paywall. A conversion that runs on your own silicon has none of those costs, which means it can simply be free and unlimited. The limits you'll actually meet are physical ones: your RAM, your patience, and the 16,383-pixel codec ceiling.

Format work rarely stops at one conversion. The same folder often needs the photographic files handled differently, or the output fed to a resizer, or — on a bad Tuesday — turned back into PNGs because a vendor's upload form was coded in 2011. These are the adjacent pages people open next:

• JPG to WebP Converter — the lossy path for photographic sources, with its own quality guidance
• WebP to PNG Converter — the return direction, alpha intact, for software that only speaks PNG
• Image Compressor — when the goal is a target file size rather than a target format