How file compression actually works

Compression feels like getting something for nothing. It is not — it is the systematic removal of redundancy, and understanding which kind of redundancy is being removed explains every confusing thing about it, including why zipping a JPEG achieves almost nothing.

The core idea: redundancy

Real data repeats itself. English text uses E constantly and Z rarely. A photograph of a sky has thousands of nearly identical blue pixels. A spreadsheet has the same words down a column.

Compression finds that redundancy and describes it more briefly. The classic illustration is run-length encoding: AAAAAAAABBBB becomes 8A4B, from twelve characters to four, perfectly reversible.

Real algorithms are cleverer but the principle holds. Two ideas do most of the work:

Dictionary compression replaces repeated sequences with references to earlier occurrences. If "the quick brown fox" has appeared before, the second occurrence becomes "go back 400 characters and copy 19". This is the LZ77 family, and it is why long documents compress better than short ones — more history to refer back to.

Entropy coding gives frequent symbols short codes and rare symbols long ones. Huffman coding does this: in English text, E might get a 3-bit code where Z gets 10. Morse code works on exactly the same principle, which our guide to the Morse alphabet covers.

DEFLATE, the algorithm inside ZIP, PNG and gzip, is these two combined — LZ77 followed by Huffman.

Lossless: getting every bit back

Lossless compression reconstructs the original exactly. Every byte returns identical.

This is compulsory for anything where a changed bit matters: program code, documents, spreadsheets, databases, archives. ZIP, gzip, 7z, PNG and FLAC are all lossless.

Typical results: plain text and code shrink by 60–80%, spreadsheets and logs often by more because they are highly repetitive, and PNG screenshots of interfaces compress very well because they contain large areas of flat colour.

There is a hard mathematical limit here. No algorithm can compress all possible inputs — if it could, you could apply it repeatedly and reduce any file to one bit. For every file an algorithm shrinks, there is one it must enlarge. Compression works because real data is redundant, not because compression is magic.

The ZIP creator and unzip tool both run in your browser, so files are never uploaded.

Lossy: throwing away what you won't miss

Lossy compression discards information permanently, chosen so that human perception is least likely to notice.

JPEG exploits the fact that eyes are far more sensitive to brightness than to colour, and poor at seeing fine detail in busy areas. It divides the image into blocks, converts each to frequencies, and discards the high-frequency detail. MP3 and AAC do the equivalent for hearing, removing sounds masked by louder ones nearby.

The ratios are dramatic — a JPEG can be a tenth the size of the equivalent PNG — which is why the entire web runs on lossy formats.

The critical property is that it is irreversible, and it compounds. Every time you open a JPEG, edit it and save again, more information goes. Do that repeatedly and artefacts accumulate visibly. Keep an original in a lossless format and export lossy copies; never edit the lossy copy repeatedly. Our guide to reducing image file size covers which lever actually moves the number.

Why some files barely compress

This is the question people actually have: why does zipping a folder of photos save nothing?

Because they are already compressed. JPEG, PNG, MP3, MP4 and most modern document formats have compression built in — a .docx is a ZIP archive already, as is an .xlsx and an .epub. Their redundancy has been removed, and there is nothing left for ZIP to find.

Well-compressed data is statistically close to random, and random data does not compress. That is also why encrypted files do not compress — good encryption produces output indistinguishable from noise. If you need both, compress first and encrypt second; doing it the other way round gives you no compression at all. The file encryptor is for the second step.

Zipping already-compressed files is still useful for bundling — one archive is easier to send than 200 photos, and the ZIP keeps folder structure and checksums intact. Just do not expect it to save space.

ZIP, and how the formats differ

ZIP compresses each file separately and stores a directory of them. That is why you can extract one file from a large archive without unpacking everything — and also why it compresses many small similar files poorly, since it cannot exploit similarity between them.

tar.gz takes the opposite approach: tar concatenates everything into one stream, then gzip compresses the whole thing. This "solid" compression handles many similar files far better, at the cost of needing to decompress from the start to reach any one file. This is why source code is distributed as tar.gz and why ZIP dominates on Windows.

7z uses LZMA with a much larger dictionary, typically achieving noticeably better ratios at the cost of speed and memory.

Zstandard is the modern answer, giving compression close to LZMA at speeds close to gzip, and it is steadily displacing both inside systems software.

A word on ZIP encryption: the original ZipCrypto is broken and should not be relied on. AES-256 ZIP encryption is sound, but note that in every case the filenames remain visible in the archive directory. If the names themselves are sensitive, encrypt the archive as a file.

Practical rules

• Compress before encrypting, never after.
• Do not re-zip already-compressed files expecting space savings. Bundle them, by all means.
• Keep a lossless master of anything you will edit again, and export lossy copies from it.
• Use the right image format — the WebP converter handles a format that beats both JPEG and PNG in most cases, and PNG remains right for text and flat colour.
• Choose the archive format for the job: ZIP for compatibility and partial extraction, tar.gz or 7z for many similar files.
• Remember that ZIP does not hide filenames.

Pikkit has the file tools, all running locally, and Web & Encoding collects the encoding and archive ones together.