A PNG quality slider cannot shrink a PNG

PNG is lossless, so dragging quality does nothing and a re-encode can grow the file; a real shrink means changing format, usually to WebP with alpha intact.

Image Compressor and Image Converter both go through Canvas toBlob. When the target type is image/png, the quality argument is omitted on purpose. Passing one would imply a tradeoff PNG does not have. The converter hides the slider as soon as you pick PNG. Believe the hide: the encode has no quality axis.

Lossless has nothing to trade

A JPEG or WebP quality number is a permission to throw bits away. 0.8 keeps most of a photograph and usually more than half of the file. 0.1 is a smear. PNG is a different contract. Every pixel you draw is stored. There is no “a bit worse, a lot smaller” knob. Dragging one is theatre.

The compressor defaults to WebP and shows the slider because WebP is lossy and that is the job: cut size while you watch the preview. The converter lets you pick PNG, JPEG, or WebP. Pick PNG and the range control goes away. That is not a missing feature. The code comment in the tool is the product: PNG ignores the quality argument entirely.

If you needed a smaller PNG that is still a PNG, you needed a different optimiser — palette reduction, extra filtering, a dedicated PNG crusher — none of which this Canvas path is. This path re-encodes the bitmap. For PNG that is often a lateral move. Sometimes it is a worse one.

A PNG-to-PNG pass can grow

The output readout compares blob size to the file you dropped. When the new file is not smaller, the page says so: larger than the original. That line is common on PNG because a browser PNG encoder is not competing with the encoder that wrote the source.

Typical reasons the re-encode fattens:

• The original was an indexed or filtered PNG. Canvas has already expanded it to a full bitmap. Writing that bitmap back as PNG stores more than the palette did.
• The original used a filter strategy the browser will not match.
• You flattened a tiny logo into an RGBA buffer and asked PNG to store every zeroed alpha sample again.

None of those are a quality setting you forgot to drag. The slider never ran. The grow is the lossless round-trip. If the readout says larger, keep the original PNG or change container. Do not drag harder.

Free tools stay on the device. Nothing is uploaded. Disconnect the network and the encode still finishes. That does not make PNG suddenly lossy.

WebP keeps the hole; JPEG fills it white

The shrink that actually works is a format change.

WebP is the usual answer. It is lossy (on this tool) at the quality you set, current browsers take it, and transparency survives. A logo with a cut-out stays a logo with a cut-out. That is why the compressor FAQ tells you to leave PNG if you need a real shrink: WebP is smaller for the same picture, alpha intact.

JPEG is the fallback when something downstream refuses WebP. JPEG has no alpha. Transparent pixels have to become a colour. This tool fills them white before encode, because an unpainted canvas encodes black — the usual surprise when a logo PNG is flattened. If you needed the hole, do not pick JPEG. If you needed a CMS that only takes .jpg, accept the white field on purpose.

PNG is the keep-it format: flat colour, real transparency, screenshots where JPEG ringing would chew the type. It is not a shrink target. Use it when lossless is the requirement, not when the landing page complained about megabytes.

Converter intro, compressed: WebP for the web, JPEG when a pipeline refuses WebP, PNG only when you need transparency or the image is already small as flat art. Compressor intro: drag quality until the preview stops looking acceptable, then stop. That sentence applies to WebP and JPEG. It does not apply to PNG.

Two tools, one constraint

Use the surfaces for the job they name.

• Compressor — the still is approved; the file is fat; you will accept a lossy encode. Default output is WebP. Watch the before/after. For photographs, quality around 0.7–0.8 usually removes more than half the file. Flat artwork, screenshots, and type degrade earlier: lossy compression parks artifacts on hard edges. Judge the preview, not the number.
• Converter — the still is approved; the container is wrong. Pick WebP, JPEG, or PNG. PNG is the lossless target. The slider is gone because it cannot help.
• Generate — the still is wrong. You need different pixels, more pixels, or a moving plate. That is a catalog row and a credit quote. It is not how you make a PNG smaller.

Do not compress, generate, then compress again. You stack artifacts and still pay the middle meter. Do not treat “quality 0.1” on a PNG as a trick; the argument never reached the encoder. If the brief is file size, change format. If the brief is the wrong product, generate.

FAQ

Why does the quality slider disappear on PNG?

Because PNG is lossless. Canvas toBlob would ignore a quality argument, so the converter does not pass one and does not show a control that cannot work. JPEG and WebP keep the slider.

I re-saved a PNG and it got bigger. Did I break compression?

No. A lossless re-encode can add overhead once the bitmap is expanded. Keep the original, or export WebP if you actually need fewer bytes. The tool labels the result when it is larger than the source; that label is the answer.

Will WebP keep my transparent background?

Yes, on this converter. That is the usual shrink for a PNG with alpha. JPEG will not: it fills transparent pixels white so they do not encode black.

Should I generate a “smaller version” of the still instead?

Only if you wanted a different still. A model restyles. The compressor and converter re-encode pixels you already approved. Format change first. Generate when the picture is the problem, not the container.