“Lossless” has a precise meaning: after decompression, the image data can be reconstructed without the losses introduced by a lossy encoder. It does not mean that every file becomes smaller, and it should not be used to describe an output that changes pixels or removes required information.
Lossless and lossy are different goals
Lossless processing is appropriate when exact reproduction matters, such as a source graphic, screenshot, diagram or an image that will be edited again. Lossy processing can be appropriate for display-only photographs when a smaller file is more important than preserving every original value.
What to check in a lossless workflow
- Keep the original and note its format, dimensions, transparency and color mode.
- Process a copy using a mode that is explicitly documented as lossless.
- Compare dimensions and transparency, and use a pixel or file comparison when exact equality is required.
- Check whether metadata changed separately from the image pixels.
Why the output may not be smaller
Lossless compression removes redundancy but cannot guarantee a reduction for every source. A file that has already been optimized, contains complex detail or uses a different internal representation may stay similar in size or become larger after conversion.
Do not confuse visual similarity with losslessness
A lossy output can look identical at normal viewing size and still differ from the source at the pixel or byte level. Describe it as visually acceptable only when that is what was checked. Use “lossless” only when the actual processing path and verification support that statement.
Three meanings of “same”
A file can have the same dimensions while its pixels differ. Two files can render identically at normal size while their bytes differ. Metadata can change while the pixels remain the same. Decide which kind of equality your workflow requires before testing; otherwise a visual inspection alone can lead to an inaccurate lossless claim.
A conservative acceptance rule
Accept the output only after it opens correctly, retains required transparency and meets the equality test chosen for the project. If the tool or format does not expose enough information to verify that test, describe the result as unverified rather than calling it lossless.
Acceptance details
A result is acceptable only when it meets the destination requirement, opens correctly and passes the visual or technical check described above. The output may be smaller, similar in size or larger than the source; record what actually happened instead of replacing the observation with a target percentage.
A reproducible equality test
First decide whether the project requires byte equality, pixel equality or only visual equality. A byte comparison is strict but can fail when harmless metadata or container information changes. A pixel comparison is more useful for an image workflow: decode both files, compare dimensions and pixel values, and report any difference. Visual inspection is appropriate for a delivery copy, but it cannot prove that a lossy file is mathematically lossless.
Format-specific decisions
JPEG does not provide a lossless export path for an ordinary re-encode. PNG is commonly used when exact pixel reproduction and transparency matter. WebP and AVIF can support lossless modes, but the selected mode and the receiving application still need to be checked. Keep the source and record the encoder mode rather than inferring it from the filename.
A useful project record
A reproducible record names the source, output format, dimensions, selected mode, comparison method and result. If pixels match but metadata changes, say so. If only a visual check was made, label the observation as visual. This vocabulary prevents a small delivery file from being described more strongly than the test supports.
Sources and further reading
web.dev’s image performance guide distinguishes lossy and lossless compression and recommends checking quality against file size. MDN’s format guide lists the compression characteristics of common web formats.