Lossless Image Formats: Which One to Use, and When Lossless Is the Wrong Choice

What lossless actually means (and three things it does not)

Lossless means the decoder reproduces the exact pixel values that were encoded. Nothing is approximated, nothing is thrown away, and you can re-save the file a thousand times without the image changing. That is the whole definition, and it is narrower than people assume: it says nothing about how big the file is, how long it takes to encode, or whether the pixels you fed the encoder were any good to begin with.

The W3C's PNG specification, which reached its Third Edition as a W3C Recommendation in June 2025, puts it plainly: the format's compression is "deterministic, reversible, and lossless". Lossless image formats get their savings the way ZIP does, by finding repetition. PNG predicts each pixel from its neighbors and hands the residual to DEFLATE; WebP's lossless mode adds a color cache and palette tricks; JPEG XL's modular mode uses adaptive prediction and context modeling. Flat colors, repeated patterns and sharp edges compress beautifully. Sensor noise in a photograph compresses badly, because noise has no pattern to find.

Three things that lossless does not mean, each of which is the subject of a forum thread that still ranks on Google's first page:

• The compression level is not a quality setting. When GIMP, Photoshop or a command-line tool asks for a PNG "compression level" from 0 to 9, it is asking how hard the encoder should search for repetition. Level 0 and level 9 decode to identical pixels; the difference is file size and encoding time. The same is true of oxipng's levels, cwebp's -m method, and cjxl's -e effort.

• "Quality 100" is not lossless. A lossy encoder at its top quality setting still runs the image through a lossy pipeline, usually a color-space conversion and a frequency transform, and gets close to the original without matching it. In our tests, AVIF at quality 100 through a common encoder path differed from the source on every image. WebP, AVIF and JPEG XL each have a separate lossless mode you have to ask for by name.

• "Compressed without losing quality" is a marketing phrase, not a technical one. It almost always means "visually indistinguishable at normal viewing size". TinyPNG, to its credit, describes its own engine as a "smart lossy compression engine". A tool that advertises lossless PNG optimization and saves 6% is usually re-packing the same pixels more tightly, which is real but is a different thing from the format-level choice this guide is about.

The lossless image formats in 2026, compared

Four formats can store a lossless image and display it in a current browser: PNG everywhere, lossless WebP everywhere, lossless AVIF everywhere, and lossless JPEG XL in Safari, in Chrome from version 155 (October 6, 2026) and in Firefox from 158 (October 13). TIFF is lossless (usually) but is not a web format; GIF and HEIF are technically capable and practically beside the point.

A few rows need a sentence each.

PNG is the baseline for a reason: it has been lossless by construction since 1996, every decoder on earth reads it, and the 2025 Third Edition brought animation and HDR signaling into the standard. Its weakness is size. Google's figures put lossless WebP at 26% smaller than PNG on average, and the JPEG XL project's own headline is that an equivalent PNG is 46% larger than a lossless JXL, which works out to JXL being about 31% smaller.

Lossless WebP was designed specifically to replace PNG on the web. Google's 2017 study across 12,000 PNGs found lossless WebP 23% smaller than ZopfliPNG-optimized files and 42% smaller than libpng's output, and smaller on more than 99% of the images. The limit is 8 bits per channel: no 16-bit masters, no HDR.

Lossless JPEG XL is the most capable of the four: 32-bit samples, alpha, animation, HDR, and a reversible transcode that stores an existing JPEG around 20% smaller and reconstructs it bit-exactly. We cover it in depth in our guide to converting images to JPEG XL. The caveat is support outside the browser, which still lags: the three big engines decode it from October 2026, most chat, mail and office software does not.

Lossless AVIF exists because AV1 has a lossless coding mode, but it was never the format's purpose. libavif only encodes losslessly with 4:4:4 chroma, quality 100 and identity (or YCgCo-R) matrix coefficients, and the results are consistently larger than lossless WebP or JXL. Johannes Siipola's widely cited 2021 comparison measured a median of 203 KB for AVIF against 148 KB for WebP and 131 KB for JXL on 94 design images, and our own numbers below say the same thing with 2026 encoders. Use AVIF for lossy, where it is excellent, and reach for something else for lossless.

TIFF is lossless when saved uncompressed or with LZW, Deflate or PackBits, which is how print and archive workflows use it, but the container can also carry JPEG-compressed data, so a .tif is not automatically lossless. No browser except Safari renders it in a web page.

GIF compresses losslessly, but converting any image with more than 256 colors to GIF quantizes it first. The format is lossless; the conversion usually is not.

HEIF / HEIC files are normally HEVC-encoded and lossy. The container allows lossless coding, but the HEIC you get from a phone and the HIF a Canon or Sony body writes are lossy by default, and lossless is not an option you will find in a camera menu.

Our benchmark: six images, four lossless formats

We ran six images through Mochify's API with lossless=1 as PNG, WebP and JPEG XL, encoded the same six as lossless AVIF with the reference encoder (Mochify has no lossless AVIF path, for reasons the table makes clear), decoded every output and compared it pixel-for-pixel with the source. Lossless WebP produced the smallest file on every flat graphic and on the transparent logo, lossless JPEG XL edged it on both photographs, and lossless AVIF was never smallest.

Method. The images are reproducible: a synthetic 1440x900 app screenshot (flat panels, anti-aliased text), a 1200x800 flowchart, a 1200x800 bar chart with smooth gradient fills, an 800x800 logo with a soft drop shadow on a transparent background, and two photographs from scikit-image's public-domain sample set (512x512 and 600x400), all saved as PNG by libpng at its default level 6. Each PNG was posted to POST /v1/squish on api.mochify.app with lossless=1 and type=png, type=webp and type=jxl, and again with no lossless parameter to get Mochify's default (lossy) WebP and JPEG XL for scale. Lossless AVIF came from libavif 1.4.2 (quality 100, 4:4:4, identity matrix). Every output was decoded and compared with the source: 17 of the 18 Mochify lossless files were byte-identical, and the eighteenth, the transparent logo as WebP, matched on every visible pixel (more on that below). Run on October 2, 2026; the scripts and raw results are in our content repo.

Four things stand out.

1. On flat graphics, lossless WebP was in a different league. On the screenshot it was 4.6 times smaller than lossless JPEG XL and 3.3 times smaller than the source PNG; on the flowchart, 3.4 times smaller than the PNG. The screenshot is exactly what WebP's lossless coder was built for: large areas of identical color and a small palette.

2. On flat graphics, the lossless file was smaller than the lossy ones. The 21.8 KB lossless WebP of the screenshot beat Mochify's own default 44.4 KB WebP and 69.4 KB JPEG XL, and the same held on the flowchart, the chart and the logo. Lossy encoders spend bytes trying to preserve the look of sharp text edges that a lossless coder simply stores. For UI, diagrams and text, lossless is not the cautious choice; it is the small one.

3. On photographs, lossless saved a fifth and lossy saved an order of magnitude. JPEG XL's lossless mode was the smallest at 325.4 KB for the 512x512 photo, 22% under the source PNG, with WebP two percent behind. Mochify's default WebP of the same photo was 23.4 KB, 13.9 times smaller than the best lossless file, and at that size the difference is invisible at normal viewing distance. That ratio is the whole argument of the "when not to use lossless" section below.

4. PNG to PNG is not where lossless savings live. Re-encoding a PNG as a lossless PNG came back between 2% smaller and twice as large as the libpng source, and 39 to 50% larger on the photographs. A lossless PNG is still a PNG; the savings come from changing format to WebP or JPEG XL. If you need a smaller file that must stay a PNG, a dedicated optimizer such as oxipng is the tool (it took 17 to 30% off our flat graphics and 1 to 2% off the photographs).

For comparison we also ran the same six files through the reference encoders at their slowest settings (cwebp method 6, cjxl effort 9, oxipng). The ranking did not change. Maximum effort bought 4 to 48% on the flat graphics (the screenshot: 16.4 KB as WebP, 56.0 KB as JPEG XL) and 1 to 4% on the photographs, and at effort 9 JPEG XL overtook WebP on the logo (11.7 against 14.3 KB). Encoding effort is a dial on every lossless encoder; it changes the size, never the pixels.

Two traps surfaced in the course of running this benchmark, and both are common enough that we reproduced them deliberately. AVIF at "quality 100" through a popular Python encoder binding, with 4:4:4 chroma but the default color matrix, was not pixel-identical on any of the six images; the 512x512 photo came out at 288 KB, smaller than any true lossless file, because it was lossy. And lossless WebP, both from Mochify and from libwebp's command-line encoder at its defaults, altered the hidden RGB values under fully transparent pixels in the logo (902 of them in Mochify's output, 381 in cwebp's). Every visible pixel and the whole alpha channel were identical, but a byte comparison fails; libwebp's exact option keeps those hidden values if you need them.

If screenshots are your main use case, our JPEG XL vs PNG for screenshots guide goes deeper on that one comparison. The lesson of this broader test is that the right lossless format depends on the picture, so the next section gives you the rule for each.

Which lossless format for which image

Pick by image content and destination, not by the format's reputation: lossless WebP for anything flat that will be viewed in a browser, PNG when the file has to open everywhere or needs more than 8 bits, lossless JPEG XL for masters and for photographs that must stay lossless, and TIFF when a print or archive workflow asks for it.

Screenshots, UI mockups, app store images. Lossless WebP, by a wide margin. Every browser in use reads it, the files were 3 to 5 times smaller than the alternatives in our test, and the lossless coder is specifically tuned for flat color and text. Keep a PNG if the screenshot is going into a document, a ticket system or a slide deck that may not accept WebP.

Diagrams, charts, line art, icons rendered to raster. Lossless WebP again, for the same reasons. If the graphic has a smooth gradient, lossless JPEG XL closes the gap but did not overtake WebP in our chart test (11.7 KB against 6.5 KB).

Logos and cut-outs with soft transparency. Lossless WebP won our test (14.9 KB against 22.4 KB for lossless JPEG XL and 32.0 KB for the PNG) and is far better supported; only at the reference encoder's slowest setting did JPEG XL pull ahead. Ship WebP; keep the JXL or PNG as the master. If the destination flattens transparent images to a background color, as several marketplaces do, no lossless format will save you; our guide to WebP and AVIF transparency covers that chain of failures.

Photographs you must keep lossless (a master you will edit again, a scan, a scientific or medical image, a legal exhibit). Lossless JPEG XL if your tools read it, because it is the smallest and keeps 16-bit and HDR data. PNG at 16 bits if they do not. TIFF if the workflow is built around it. Do not use lossless WebP for this: it is 8-bit only, so a 16-bit master would be silently truncated before it was "losslessly" stored.

Photographs for a web page, a listing, a message, a social post. Not lossless. See the next section.

An existing JPEG. Leave it as a JPEG. Converting a JPEG to PNG, lossless WebP or lossless JXL produces a much larger file that faithfully preserves the JPEG's compression artifacts; you have paid in bytes for a perfect copy of an imperfect image. The one exception is JPEG XL's reversible transcode, which stores the JPEG itself around 20% smaller and can give you the original bytes back; that is a feature of the cjxl encoder, and converting through a tool that decodes and re-encodes the pixels, which is what most converters including our own JPG to JXL page do, is a lossy re-encode rather than a transcode.

Animation. Animated WebP for the web; APNG where you need lossless frames and broad decoder support; animated JXL where the audience is on Chrome 155+ or Firefox 158+ (Safari does not play animated JXL).

When lossless is the wrong choice

For photographs that will be looked at rather than edited, lossless is the wrong choice almost every time: in our test the best lossless photo file was 13.9 times the size of Mochify's default WebP of the same photo, which is visually indistinguishable at normal viewing size. The question to ask is not "do I want to lose quality" (nobody does) but "will anyone ever see the difference, and what does avoiding it cost".

Lossless formats hunt for repetition, and photographs contain very little of it. Every pixel of sky is a slightly different shade; every edge is softened by the lens; the sensor adds noise that is, by definition, random. A lossless encoder has to store all of that. A lossy encoder is allowed to drop the noise and the detail your eye cannot resolve, and that is where the 13.9x comes from. Lossy photo formats have also improved a great deal: WebP, AVIF and JPEG XL at moderate quality settings, and even standard JPEG through Google's jpegli encoder, deliver files that pass visual inspection at a fraction of lossless size. Our Jpegli guide shows how far the plain JPEG has come.

There are three honest reasons to keep a photograph lossless, and they are all about the future rather than the present: you will edit it again (each lossy re-save compounds), you need it as evidence or a scientific record, or you are archiving a master from which every delivery copy will be made. For those, use lossless and accept the size. For everything else, including the listing photo, the blog hero, the message attachment and the social post, a well-encoded lossy file is the right answer, and "compress without losing quality" means "compress so that nobody can tell", which modern encoders do very well.

If you are not sure which side of the line an image falls on, mochify.app defaults to a single high-quality encode on every surface; you only reach for lossless when you have a reason to.

Browser and app support for lossless formats in 2026

PNG and lossless WebP open in every browser in use, lossless AVIF in all current ones, and lossless JPEG XL in Safari, in Chrome 155 and later (released October 6, 2026) and in Firefox 158 and later (October 13). This section describes the state on October 7, 2026; installed browsers take weeks to update and Edge had not shipped the change, so caniuse.com/jpegxl is the live reference if you are reading this later.

• PNG: universal, including APNG animation in every major browser.

• WebP (lossless and lossy): 96.8% of browsers in use. Chrome since version 32, Firefox since 65, Safari since 14 on macOS Big Sur or later (full support from Safari 16).

• AVIF (lossless and lossy): 95.4%. Chrome 85, Firefox 93, Safari 16.4 (16.1 to 16.3 partial), Edge 121.

• JPEG XL: Safari 17 and later decodes still images. Chrome 145 to 154 ship the decoder behind the #enable-jxl-image-format flag; Chrome 155, released on October 6, 2026, decodes JPEG XL by default on desktop and Android. Firefox compiled JPEG XL into release builds from version 152 behind a Firefox Labs toggle and enables it by default from Firefox 158, released October 13, 2026; version 157 does not. Check caniuse.com/jpegxl for the live picture, and read our guide to JPEG XL in Chrome and what changes now for the rollout caveats and how to serve JXL with a fallback.

• TIFF: Safari only, in web content. Every desktop image editor, and every print workflow, reads it.

Outside the browser, the picture is simpler than it looks. macOS and iOS open PNG, WebP, AVIF and JPEG XL natively in current releases. Windows 11 reads PNG and WebP natively, relies on Microsoft Store extensions for AVIF in some configurations, and JPEG XL support there depends on the app. Design tools and office suites nearly all take PNG and increasingly WebP; JPEG XL is still the one to check before you send a file to someone whose software you do not know.

Five ways a "lossless" file ends up lossy

A lossless format only guarantees that what the encoder received comes back out; it cannot protect you from what happened before the encoder, or from a setting that quietly switches the lossless mode off. Five of these account for nearly every "but it was lossless" complaint.

1. Bit-depth reduction on export. Some export paths write 8 bits per channel from a 16-bit document (Photoshop's Quick Export is the commonly reported example, while Save As keeps 16). Lossless WebP is 8-bit by design. A 16-bit master "losslessly" saved through either path has lost half its precision before compression started. If the bit depth matters, confirm it in the output file.

2. Quality 100 instead of the lossless mode. WebP, AVIF and JPEG XL each have a lossy pipeline that runs even at the top quality setting. In our test, quality-100 AVIF differed from the source on every image. Look for the explicit flag: -lossless in cwebp, -d 0 in cjxl, --lossless in avifenc, and, on Mochify, the word "lossless" in the prompt, the Lossless switch, or the lossless=1 parameter.

3. Transparent-pixel cleanup. libwebp's lossless encoder, by default, is free to change the RGB values hidden under fully transparent pixels to improve compression. The image looks identical and the alpha is exact, but a byte comparison fails. If you need bit-exact RGBA, use the exact option.

4. Palette conversion. Saving to GIF, or to an 8-bit paletted PNG, quantizes any image with more than 256 colors. The compression that follows is lossless; the quantization was not.

5. Color-space and profile conversion. Converting between color spaces (Display P3 to sRGB, say) before encoding rounds every pixel, and the lossless encoder faithfully stores the rounded result. Keep the source profile when you need exactness, and embed it rather than converting.

A sixth is worth a sentence because it is not pixel loss but is data loss: stripping metadata. Removing EXIF makes a file smaller and more private and leaves every pixel untouched, so a file with its metadata stripped is still lossless in the image sense. Just know that the capture date, camera and GPS are gone, which is usually the point.

Mochify Workflow: a pixel-exact JPEG XL, WebP or PNG

Mochify's default on every surface is a single high-quality encode, so lossless is a choice you make deliberately, in one of three ways: say "lossless" in a Magic Flow prompt, turn on the Lossless switch on the PNG to JXL converter, or set the lossless parameter on the API. All three give pixel-exact JPEG XL, WebP or PNG. Here is the workflow for the cases above.

Privacy note for images. Whichever surface you use, the image travels over HTTPS to api.mochify.app, is encoded in memory, and is wiped immediately: no disk writes, no logs containing file data, and never used to train AI. The CLI and local MCP server return the result straight to your machine; the hosted MCP server holds only the compressed output behind a short-lived files.mochify.app URL for about five minutes so the agent can fetch it. Images are not processed on your device, so we do not describe them as never leaving it. (That line is true only of Mochify's video tools, which run entirely in the browser.)

Cheat Sheet

Ten-second version: flat graphics, lossless WebP; photos, good lossy; masters, lossless JXL or 16-bit PNG; never lossless AVIF.

FAQ