Lossless Image Compressor Comparison: Speed, Ratio, and Compatibility
Introduction Lossless image compression reduces file size without changing pixels — essential for archival, photography, screenshots, and any workflow that must preserve exact image data. This comparison focuses on three practical metrics: compression ratio (how small files get), speed (compress/decompress time), and compatibility (formats, platforms, and workflow fit). Recommendations at the end give concise choices by use case.
Key concepts
- Compression ratio: percent or bytes saved vs original. Higher = better storage savings. For many photographic inputs, modern codecs (JPEG-XL, WebP lossless) and optimized PNG pipelines can beat generic PNG tools.
- Speed: split into compression (usually slower) and decompression (usually fast). Single-threaded tools emphasize algorithmic efficiency; multi-threaded/SIMD builds and native binaries are faster.
- Compatibility: supported file formats, OS availability, integration (CLI, GUI, APIs), and whether processing is local (no uploads) — important for privacy and batch workflows.
Top codecs/tools (practical summary)
-
JPEG-XL (lossless mode)
- Ratio: Excellent on many photographic images; often smaller than PNG and lossless WebP for color photos.
- Speed: Compression can be slow at maximum settings; decompression is fast.
- Compatibility: Growing support (decoders, libjxl, some browsers via tools), not yet universal in legacy workflows.
- Best for: Archival of photos where smaller size and future-proofing matter.
-
WebP (lossless)
- Ratio: Very good for many web images and screenshots; sometimes slightly larger than JPEG-XL on photos.
- Speed: Reasonable compression speed; fast decompression.
- Compatibility: Broadly supported in browsers and tooling; good ecosystem for web use.
- Best for: Web delivery when browser support and tooling matter.
-
PNG (optimized pipelines: zopflipng, pngcrush, oxipng, ECT, Pingo)
- Ratio: For screenshots, graphics, and images with large flat regions, optimized PNG pipelines (zopfli/zopflipng, ECT) often give the best lossless results. On complex photos PNG is usually larger than JPEG-XL/WebP.
- Speed: Tools using Zopfli are slow but yield better compression; oxipng and ECT balance speed and size; zopflipng -19 is slowest but best for maximum size reduction.
- Compatibility: Universal (PNG everywhere). Tooling: CLI and desktop GUIs available.
- Best for: UI assets, screenshots, icons, and any case requiring universal PNG support.
-
JPEG-LS
- Ratio: Competitive on certain photographic and medical images (especially near-lossless modes).
- Speed: Very fast decode and competitive encode.
- Compatibility: Niche; used in medical imaging and some specialized apps.
- Best for: Specialized workflows needing fast, lossless JPEG-compatible compression.
-
JPEG2000 (lossless)
- Ratio: Good for high-bit-depth and some photographic content.
- Speed & Compatibility: Slower and limited mainstream support; used in imaging and archival contexts.
- Best for: Specific archival systems that already use JPEG2000.
-
QOI (QuickImageFormat) / QOIR
- Ratio: Much larger than PNG or modern lossless codecs for photographic images; very fast encode/decode.
- Compatibility: New and simple; not broadly supported in apps.
- Best for: Fast intermediate storage where speed matters more than space.
Representative tool ecosystem (desktop, CLI, web)
- ImageOptim / RIOT / Trimage / PNGGauntlet / ImageMagick
- Use multiple optimizers under the hood (optipng, pngcrush, advpng, jpegoptim). Good for batch desktop workflows.
- zopflipng / zopfli / oxipng / ECT / Pingo
- CLI-focused; best for power users seeking maximum PNG shrink.
- libjxl / cjpeg/cjpeg-like wrappers (JPEG-XL)
- Use for archival and where client tooling supports it.
- cwebp / dwebp (WebP)
- Widely supported tooling and libraries; good compromise for web images.
- Squoosh, TinyPNG, xpacto (browser/web apps)
- Convenient for quick conversions; many run client-side (Squoosh, xpacto) or server-side (TinyPNG). Check privacy/batch limits.
Benchmark patterns and practical trade-offs
- For screenshots and graphics: optimized PNG pipelines (ECT, Zopfli, pngcrush) usually win on size. If speed is critical, use oxipng at medium levels or ECT fast mode.
- For photos: JPEG-XL lossless often gives the smallest files; WebP lossless is a close, more-compatible alternative.
- If you need universal compatibility with zero client changes: optimized PNG or standard JPEG (lossy) are safest.
- If throughput matters (CDN or realtime processing): choose faster encoders (oxipng medium, libwebp with faster presets, or QOI for extreme speed).
- Decompression is generally fast across modern lossless codecs; compression is where most time is spent.
Presets and recommended settings
- PNG (oxipng): use -o4 for a balance; -o6/-o7 for best size if CPU time is acceptable. Combine with zopflipng for an extra step when space is critical.
- Zopfli/zopflipng: use for final pass on assets that rarely change (heavy CPU but max shrink).
- JPEG-XL: encode with high-quality lossless preset (reference encoder flags vary); test a representative subset first.
- WebP lossless: use -m 6 or -m 9 for better compression; weigh CPU cost.
- Batch workflows: prefer CLI + multi-threading wrappers; use lib-based servers for large-scale pipelines.
Compatibility checklist before switching codecs
- Can your target viewers/browsers/clients decode the format natively?
- Does your asset pipeline (CMS, image CDN, design tools) accept and preserve the format?
- Are there toolchains for thumbnails/previews?
- Is storage or network cost more important than client compatibility?
Short recommendations (by use case)
- Best for archival photos (space-first): JPEG-XL (lossless) — convert with libjxl.
- Best for web photos (compatibility + size): WebP lossless (if your platform supports it) or convert to efficient lossy WebP/AVIF when lossy is acceptable.
- Best for UI assets/screenshots/icons: Optimized PNG via oxipng + zopflipng or ECT.
- Best for fast batch / CI pipelines: oxipng (medium) or libwebp with faster presets.
- Best for maximum compatibility with minimal fuss: PNG (optimized) for graphics; keep JPEG for photographic lossy where exact losslessness is not required.
Workflow example (practical pipeline)
- Classify image: screenshot/graphic vs photograph.
- If graphic/screenshot: run oxipng -o4, then optional zopflipng -y -m 15 for final pass.
- If photograph and clients support modern formats: encode lossless JPEG-XL; otherwise encode lossless WebP or use carefully tuned lossy WebP/AVIF for huge savings.
- Store original master (uncompressed or lossless archive) and serve optimized derivatives via CDN.
Conclusion No single lossless compressor wins every time. Choose by asset type and constraints:
- Graphics/screenshots → optimized PNG toolchain (oxipng, zopflipng, ECT).
- Photographs → JPEG-XL (best size) or WebP lossless (wider support).
- Fast pipelines → oxipng medium or fast libwebp presets.
Test a representative sample of your images with candidate tools and measure both size and processing time before rolling out a format change.
If you want, I can run a short, specific benchmark plan (5–10 representative images) and produce exact size/time numbers and recommended commands for your platform.