DigImg

Which format should I choose?

Every number below was measured once, on 2026-10-15, in Chrome on Windows, from a single 1200×630 photographic JPEG weighing 73.5 KB, at each format's default quality. Treat them as an ordering, not a promise — your image, dimensions and quality setting will move them.

AVIF — smallest, slowest

8.5 KB from the 73.5 KB source (−88.5%), and it took 7.3 s to encode. Best for images you compress once and serve thousands of times. Worst for anything interactive, because encode time grows with pixel count.

WebP — the safe default

18.6 KB (−74.6%), encoded in well under a second, and supported by essentially every browser still in use. When you do not want to think about decoder support, use this.

JPEG XL — good ratio, very fast, weak support

27.8 KB (−62.1%) in 0.4 s, and it has a genuine lossless mode. The catch is on the other side: mainstream browsers still do not decode it, so JXL is an archival or self-hosted-pipeline format, not a web-delivery one.

JPEG via mozjpeg — maximum compatibility

31.7 KB (−56.8%) with progressive scanning and optimised Huffman tables. Use it when the consumer might be anything at all: email clients, old CMS upload filters, office software. Re-encoding a JPEG does lose a little more quality each generation — start from the original file, not from an already-compressed export.

PNG — lossless, for flat colour and text

509.5 KB for that photo, i.e. roughly seven times the source. That is not a bug: PNG is lossless and cannot represent photographic noise cheaply. PNG is the right answer for logos, screenshots with text, diagrams, and anything with transparency.

oxipng — lossless PNG optimisation

230.9 KB, which is 54.7% smaller than the plain PNG of the same pixels (509.5 KB) with zero pixel change — it only finds a better deflate encoding. Note the framing: oxipng's value is measured against the PNG it started from, not against a lossy JPEG. Any tool that compares a lossless optimiser to a lossy file is flattering itself.

What this tool does not do

• No HEIC / HEIF. There is no HEIC decoder in this codec set, so iPhone .heic files are rejected with a message, not silently mangled.
• No metadata. Output carries no EXIF, no colour profile and no GPS, because pixels are decoded and re-encoded. Measured, not assumed — see the FAQ.
• No batch or ZIP. One file in, one file out, per run.
• No animation. Animated GIF/WebP is flattened to its first frame.
• No server, no queue, no account. Which also means no processing power beyond your own machine: very large images can exhaust browser memory and will fail with an error rather than produce a partial file.

How it works, and how to check

Decoding and encoding run as WebAssembly compiled from the same codecs Google's Squoosh project uses — libavif, libwebp, libjxl, mozjpeg, oxipng — loaded lazily per format (0.13 MB for WebP, 3.4 MB for AVIF). The page itself is 10.9 KB gzipped; nothing codec-related is downloaded until you pick that format. Resampling uses squoosh's resize and hQx kernels, with a step-down canvas fallback that the pipeline line reports openly rather than hiding.

To verify the "no upload" claim instead of taking my word for it: open DevTools → Network, run a compression, and confirm no request carries your file. The codecs are squoosh derivatives under the Apache-2.0 licence; full attribution is generated from the exact dependency versions in the build.

Questions people actually ask