Lossy vs Lossless Compression: What Can Be Recovered?

A photograph is exported as a small JPEG for a web page, then later converted to PNG for editing. The PNG can preserve the pixels produced by decoding that JPEG. It cannot recover detail already discarded during the earlier JPEG encoding. Changing to a lossless format prevents another kind of loss; it does not reverse the history of the image.

That distinction is central to compression choices. Lossless compression preserves a defined input exactly on decoding. Lossy compression permits irreversible changes to that input to obtain a representation suited to the intended use. The practical question is what needs to survive: original file bytes, pixel values, audio samples, a readable document, or an acceptable presentation to a person.

State What the Word Lossless Refers To

For a general-purpose byte compressor, the input is a sequence of bytes and decompression must reproduce that sequence. A source-code archive or compressed database backup needs this kind of exactness. A slightly altered executable is not an acceptable approximation merely because it looks similar in a file viewer.

For a media codec, the preserved representation may be decoded samples or pixels rather than the original container file. Metadata, colour conversion, resampling, and the handling of unsupported features can introduce separate changes around the compression step. A lossless codec cannot guarantee that every stage of an import-and-export workflow is lossless.

For example, encoding PCM audio as FLAC preserves the supported audio sample data under the format. It does not automatically promise a byte-identical reconstruction of every original WAV file, with all its chunks and metadata. The FLAC specification defines the audio coding format and its supported representation.

Write down the preservation requirement before selecting a format. “Retain the original uploaded file” is different from “retain the decoded image pixels.” Both can be legitimate requirements, but a test for one does not establish the other.

Lossless Methods Reorganise Information

Lossless compressors exploit structure such as repeated sequences or predictable symbol patterns. Instead of storing every occurrence independently, they can encode references and other compact descriptions, with enough information for the decoder to reconstruct the input exactly.

DEFLATE, used by common compression tools, combines repeated-string references with Huffman coding. This is an example of a lossless representation, not a method for deciding which source content is unimportant. The decoder reconstructs the coded byte sequence according to the format.

Compression effectiveness depends on the data. Repeated text may shrink substantially, while already compressed or high-entropy input may offer little reduction. Headers and representation overhead can make some compressed outputs larger than their input. Lossless does not mean smaller in every case.

No reversible compressor can make every possible input shorter. There are not enough shorter representations to give every distinct input its own unique reversible code. Practical compressors therefore exploit structure in the inputs they target, and may store difficult content with limited overhead instead of guaranteeing a saving.

Lossy Methods Permit Approximation

Lossy coding represents the source with changes allowed by its design and settings. For images, this can involve reduced precision and less detailed colour information. Audio and video codecs can exploit perceptual properties and relationships across samples or frames. Their goal is a useful reconstruction at a selected resource cost, not exact recovery of the original signal.

The familiar photographic JPEG workflow is usually lossy. Aggressive settings can introduce blocking, ringing, colour changes, or loss of fine detail. The amount and visibility depend on content, settings, implementation, and display conditions; there is no universal quality percentage that describes every encoded photograph.

Lossy does not necessarily mean visibly poor. A delivery image can look suitable at its intended size while using fewer bytes than a source retained for editing. Conversely, a subtle change that a viewer ignores may matter to OCR, measurement, or later image analysis.

An AI enhancement can generate plausible detail after information has been discarded, but plausibility is not exact recovery. If several different originals could produce the same lossy representation, decoding that representation alone cannot identify which original was used. Generated detail should not be presented as proof of what the source contained.

Distinguish Formats, Codecs, and Containers

A filename extension is not always a complete statement of compression behaviour. A container can carry streams encoded by different codecs, and a format can support more than one mode. Determine what the actual file contains and how it was produced.

PNG defines lossless image storage. The PNG specification describes its image representation and compression. Saving an image as PNG does not establish that the editor preserved the original bit depth, colour information, metadata, or pixels before encoding. Those are separate steps to verify when they matter.

WebP supports both lossy and lossless coding, as Google’s compression documentation explains. A statement that every WebP image is lossy would therefore be incorrect. Likewise, MP4 is a container rather than a single rule about whether its streams preserve samples exactly.

ZIP is also a container with specified storage and compression methods. PKWARE’s ZIP format specification includes the uncompressed stored method as well as compression methods. A normal file-archive workflow should recover each entry’s content bytes exactly, but rebuilding an archive need not reproduce the archive’s original ordering, timestamps, or other container bytes.

Preserve a Master and Derive Delivery Versions

A master-and-derivative workflow separates preservation from distribution. Retain the source required by policy, perform edits in an appropriate working representation, and generate delivery versions for the actual audience. One file does not have to satisfy every storage, editing, and bandwidth objective.

Generate each derivative from the intended master rather than a previously compressed thumbnail. Otherwise a larger export can contain fewer reliable details than its dimensions suggest. Retain the relationship between source and derivative when an investigation or later replacement needs to establish how it was produced.

Re-encoding through a lossy path can introduce generation loss. The effect depends on the codec, settings, transformations, and whether the data is actually decoded and encoded again. Copying a file does not cause generation loss, and some operations can preserve compressed data without a complete lossy re-encode.

The vector and raster comparison addresses another part of this decision. Rasterising a vector changes the representation before image compression begins. A lossless PNG of that raster is not the same preservation claim as retaining the original vector document.

Evaluate Size Alongside Processing Cost

Measure the complete workload. A codec that saves bandwidth may use more CPU, memory, or encoding time. A format that decodes efficiently may not achieve the smallest file. For interactive delivery, device support and decoding behaviour can matter as much as the storage ratio.

Compare like with like: dimensions, sample rate, channel count, bit depth, required metadata, and quality. Reducing image dimensions can produce a substantial saving independently of the codec’s compression efficiency. Do not attribute all of that reduction to switching formats.

Already compressed media often yields little additional saving inside a general archive. The exact result depends on residual redundancy and overhead. Measure representative files rather than assuming that every second compression pass is pointless or that it must save another fixed percentage.

Encoding is a separate transformation. Base64 typically expands binary data when carrying it through text, as the Base64 and hex article explains. Compression before text encoding and compression of the final transport payload can have different costs and results. Evaluate the path actually used by the application.

Verify Recovery at the Right Boundary

For byte-preserving compression, compare decompressed content with the original. A small Python example demonstrates the property without implying a useful saving for every input:

import zlib

source = b"repeatable record\n" * 100
encoded = zlib.compress(source)
assert zlib.decompress(encoded) == source

The example tests a round trip for that input. It is not a test of a complete archival system, storage durability, or every possible file. The checksum article explains how integrity checks help detect unintended changes, with the algorithm and trust boundary chosen for the purpose.

For media, test the required pixels, samples, metadata, and rendering behaviour separately. For lossy delivery, inspect representative difficult material and evaluate any downstream task such as OCR. A person approving a thumbnail and a model measuring a small feature can require different evidence about the same image.

Choose lossy compression where the permitted approximation is established and useful. Choose lossless preservation where exact recovery of the defined source matters, and retain the original file when that is the actual requirement. The decision becomes clearer once size, quality, representation, and recoverability are described as separate properties.