Lossless PNG with OxiPNG: when pixel perfection still matters

There is a recurring claim in performance writing that PNG is a legacy format and everyone should be on WebP or AVIF by now. That advice is correct for photographs. It is wrong for everything PNG was actually designed for: UI assets, icons, screenshots, technical diagrams, and any image where a single re-quantized pixel would be visible.

For those workloads, lossless compression is not a preference. It is a requirement. And lossless PNG is still the right format. The only question is which tool to use to shrink the file without touching the bits inside. The answer, in 2026, is OxiPNG.

图像压缩器

批量压缩为 WebP、AVIF、JXL，支持高级参数调节

→

What lossless actually means here

PNG files have two layers of compression. The first is the way the encoder predicts each pixel from its neighbors and stores only the difference (called filtering). The second is the DEFLATE compression pass that runs over the filtered data. Most PNG files were saved with default filter and DEFLATE settings, which are conservative and leave a surprising amount of redundancy on the table.

A "lossless PNG optimizer" is any tool that re-runs that filter and DEFLATE pass with smarter heuristics, producing a smaller PNG file that decodes to bit-identical pixels. Nothing changes about the pixels themselves. The image looks identical. The file just gets smaller.

For typical UI screenshots, the savings range from 20 to 60 percent. For already-aggressively-saved exports from a design tool, the savings can be smaller (5 to 15 percent). For PNGs exported from a screenshot tool with default settings, the savings are usually substantial.

The optimizer landscape, briefly

Five tools come up in PNG optimization conversations. They behave differently enough to be worth knowing about.

OxiPNG. Rust-native, fast, has a WASM build that runs in browsers. Effort settings 0 through 6 trade encoding time for output size. The default setting (effort 2 or 3, depending on version) is a sensible balance. Effort 6 takes much longer and squeezes out a few extra percent.

Zopfli (and zopflipng). Google's reference tool. Compresses better than OxiPNG in roughly 87 percent of cases but is significantly slower. Has historically been the gold standard for "I will trade time for the smallest file possible."

OptiPNG. Older C tool, fast, somewhat less effective than OxiPNG on most inputs. Still in wide use because it is in every Linux package manager.

Pngcrush. Older still, slower than OptiPNG, similar output. Maintained for compatibility, not for results.

FileOptimizer. Windows-only meta-tool that runs multiple optimizers in sequence and keeps the smallest output. Highest compression possible, very slow.

The honest summary: zopflipng is the smallest output, OxiPNG is the best speed/output tradeoff, the older tools are mostly obsolete unless you have an existing pipeline that depends on them.

Why OxiPNG is the practical choice in a browser context

The image-compressor tool runs OxiPNG via WebAssembly, which means a few useful things:

1. The optimization happens entirely on your machine. Nothing uploads.
2. You can drop a folder of PNGs in and have them all re-encoded in one pass.
3. The effort setting is exposed, so you can dial up for archival exports or dial down for fast iteration.
4. The output is bit-identical to running OxiPNG locally, because it is OxiPNG.

The limitation is that for the very smallest possible file, zopflipng would win on most inputs. The difference is usually 2 to 5 percent. For most UI work that is not worth the wait. For an icon library you are bundling into a million app installs, it might be.

When to use lossless PNG instead of WebP lossless or AVIF lossless

Both WebP and AVIF have lossless modes, and they are sometimes smaller than the equivalent PNG. The decision rule:

Use lossless PNG when: the image is a screenshot, UI asset, icon, or technical diagram. The file is consumed by something that expects PNG (favicons, GitHub READMEs, design system spec docs, native app builds, print pipelines, certain CMSes that don't fully understand WebP).

Use lossless WebP when: the image has transparency, will be served on the web, you control the markup, and the consumer is a modern browser. Lossless WebP is often 25 to 50 percent smaller than the equivalent PNG for assets with any color complexity.

Use lossless AVIF when: almost never. AVIF's lossless mode has improved but is rarely the right call for the kind of content where lossless matters. For photos you want lossy AVIF; for graphics you want either lossless WebP or lossless PNG.

What the tunable settings actually do

OxiPNG exposes three useful knobs in the in-browser compressor.

Effort. Range 0 to 6. The default is in the middle. Effort 0 is roughly "decompress and recompress at the same level" and produces small savings. Effort 6 tries every reasonable combination of filter and compression strategy and picks the best one, which can take 10 to 30 times longer for marginal additional savings. The middle settings are the sweet spot for most users. Crank to 6 only when the file will be served to many users and the byte savings amortize.

Interlace. Off by default. Interlaced PNGs render progressively from blurry to sharp during slow downloads, which used to matter on dial-up and is mostly cosmetic on modern connections. Interlacing also makes the file slightly larger. Leave it off unless you have a specific reason to enable it.

Optimize alpha channel. On by default. Re-checks whether pixels with an alpha value of zero (fully transparent) have RGB values that could be set to a constant to improve compression. The visual result is identical because those pixels are invisible anyway, but the file gets smaller. No reason to disable this.

A workflow that actually saves bytes

For a folder of UI screenshots or design exports:

1. Drop the entire folder into the compressor at once.
2. Set output type to OxiPNG.
3. Set effort to 4. (Higher than default, lower than maximum, good ratio of speed to savings.)
4. Run, download the resulting ZIP.
5. Compare the total folder size before and after. For a typical batch, expect the new folder to be 30 to 50 percent of the original.

For a single hero asset that will be served to a lot of users:

1. Encode at OxiPNG effort 6.
2. Compare against the same image encoded as lossless WebP.
3. Pick whichever is smaller for your specific image. (For graphics with multiple flat colors, WebP usually wins. For photos with many colors that you somehow have as PNG, PNG itself usually wins because lossless modes hate photos.)

For an icon library that ships in millions of app installs:

1. Encode each icon as PNG8 if the color count allows it.
2. Run those PNG8 files through OxiPNG at effort 6.
3. Verify the smallest possible output.
4. Bundle.

The byte savings on the third workflow can be enormous because the savings multiply by every install.

What this is not

OxiPNG is lossless. It will not magically make a photograph smaller, because photos do not respond well to lossless compression, period. It will not strip image metadata for privacy purposes; that is a separate operation and the in-browser compressor does not currently do it. It will not convert PNG to WebP or AVIF; that is what the format-conversion side of the same tool does.

Lossless PNG optimization is a narrow, useful operation that pays off whenever pixel perfection is the requirement. For the workloads it serves, OxiPNG is the practical answer in 2026, with zopflipng as the heavyweight alternative when squeezing the last few percent matters more than time.

Z.Tools·z.tools

Image Compressor · Z.Tools

Batch compress to WebP, AVIF, JXL with advanced controls