PNG Compression: Set Quality Slider 60%, Keep Transparency

Set a PNG to 60 percent quality in the browser and it can come out bigger than the original. Here is the code that explains why.

I benchmarked this exact thing and the result annoyed me. I dropped a 200KB transparent PNG into a browser-based compressor, slid quality to 60, and the output landed near 70KB — sometimes. On a different image, same slider, same tool, the file came out 210KB, slightly larger than what I fed in. The slider did not lie, exactly. It just was not doing what the label promised on PNG.

The reason is in four lines of the tool's own source, and once you see it you will never trust a "quality" percentage on a PNG the same way again. The short version: a browser canvas only honors the quality argument for lossy formats. PNG is not one of them.

The four lines that decide whether your slider matters at all

This is the compression core, lifted straight from the page's JavaScript:

var mime = webpOn() ? "image/webp" : (item.file.type || "image/jpeg");
if (mime.indexOf("jpeg") === -1 && mime.indexOf("jpg") === -1
    && mime !== "image/webp"
    && item.file.type === "image/png") mime = "image/png";
var q = quality() / 100;
var blob = await canvasToBlob(c, mime, q);

Follow the PNG path through it. You drop in a PNG and you do not toggle WebP. The first line sets mime to the file's own type, so mime is now image/png. The second line is a guard that keeps PNG as PNG rather than letting it fall back to JPEG. Good so far. Then the third line computes your slider value as a 0 to 1 fraction and the fourth hands it to canvas.toBlob(canvas, "image/png", 0.6).

That last argument is where the promise breaks. Per the canvas spec, the quality parameter for toBlob and toDataURL "applies only to image formats that support lossy compression." PNG is a lossless format. So the browser encodes your PNG with its normal lossless pipeline and silently ignores the 0.6 entirely. Run the slider from 10 to 100 on a PNG and you get the same file. The number you moved was never read.

So why did my file get smaller at all — or bigger?

Two different effects are mixed together, and separating them is the whole game.

The first is re-encoding. A browser canvas holds RGBA pixel data. When you draw your PNG onto the canvas and ask for a PNG blob back, the browser re-runs PNG compression with its own encoder settings. On a file that was already optimized, that second pass can go either way. A bloated PNG exported from an editor with a huge palette often shrinks simply because the canvas encoder is more efficient. An already-tight PNG can grow, because the canvas re-encoding is not as good as the original optimizer. That is the 200KB to 70KB you saw, and also the 200KB to 210KB. The slider had nothing to do with either.

The second effect is the WebP toggle. If you turn WebP on, the first line flips mime to image/webp, and now the quality argument is honored for real, because WebP supports lossy compression. Drop the slider to 70 with WebP on and you get a genuinely smaller file with the alpha channel preserved. Drop it to 70 with WebP off and you have changed a number that gets thrown away.

Read that middle row twice. If your goal is smaller transparent images, the WebP toggle is the only control on this page that does what the quality slider claims it does.

Does transparency survive? Yes, and here is why PNG is safe

A PNG image stores an alpha channel: 256 possible levels of transparency per pixel, 0 fully clear to 255 fully opaque. Those intermediate values are what make a soft drop shadow fade cleanly and a cutout edge look smooth instead of stair-stepped.

When this tool keeps your file as PNG, the canvas pipeline carries the alpha channel straight through. The lossless encoder preserves every alpha value exactly. Nothing about PNG compression in a canvas touches transparency, whether the slider says 10 or 100. Set the slider to 100 and you still get the same PNG bytes, alpha intact.

The way people actually lose transparency is by picking the wrong output. Toggle WebP off and drop a PNG into a tool that defaults to JPEG output and you get an opaque image with a black or white background where your cutout used to be. The FAQ on this page calls that out, and it is the real failure mode. It has nothing to do with the quality percentage and everything to do with which format the pipeline chose.

The workflow that actually shrinks transparent PNGs

1. For the tightest transparent images, switch to WebP. Turn the WebP toggle on. Now the quality slider is live, and 70 to 80 percent typically halves the file while keeping the alpha channel.
2. If you must stay on PNG, ignore the quality slider. Set it anywhere, the output is the same. Judge the result purely by the before and after file sizes the tool reports, not by the number you set.
3. Watch the size meter, not the slider. The tool shows original and compressed bytes for each image. That delta is the only signal that reflects reality for PNG.
4. Never let the format fall to JPEG. If a transparent image comes out with a dark or white block behind it, the pipeline switched formats. Force PNG or WebP and compress again.
5. Re-check your PNGs that grew. If a canvas re-encode made a file larger, its original optimizer was already better than the browser. Keep the original for those, and only route the bloated ones through the tool.

A 60 percent slider that does nothing beats a 60 percent slider that quietly ruins your alpha channel

The comfortable framing is "the slider is broken." The accurate framing is that the tool refused to run a lossy pass on a lossless format, and that refusal is the reason your transparency is still perfect. The number is cosmetic for PNG, and the format guard in the source is what protects your cutouts.

So judge the tool by the right metric: for PNG, the quality slider is decoration and the file-size delta is the truth; for WebP, the slider is real and 70 to 80 percent is your sweet spot. Move to WebP when you need smaller transparent files, and treat the PNG slider as the harmless no-op it actually is. Your alpha channel will thank you either way.