What file compression is

What compression actually does

Compression means writing the same content with fewer bytes by finding repetition. The idea is simpler than it sounds. If a text says the word "hello" thirty times, instead of writing it thirty times you write it once and point at it twenty nine times. The program that opens the file rebuilds the original text from those pointers.

So the more repetition a file has, the more it collapses. Text is full of repetition and gains the most.

An example from this very site: the stylesheet of the rgb.ir theme is 129 KB as it stands. The same file through gzip becomes 32 KB. About a quarter, without a single character being lost.

Lossless or lossy: the difference that decides everything

This is the only division in compression that genuinely matters; everything else is detail underneath it.

Lossless compression promises that the file coming out is byte for byte the file that went in. ZIP, RAR, 7z and gzip all belong to this family. For documents, code, spreadsheets and anything where a single byte counts, this family is the only usable one.

Lossy compression makes a different promise: I will make this much smaller, provided you let me throw away things the human eye and ear usually do not notice. A JPEG photo, an MP3 track and an MP4 video are all products of that bargain. What was thrown away does not come back. Opening the file again does not revive the lost detail, because it is no longer inside the file.

There is a simple way to see the difference. We compressed a file with gzip and opened it again, and the digital fingerprint of both copies was exactly the same; the thing we call a checksum in the safe software install lesson. No lossy file passes that test, and none is meant to.

Why zipping a folder of photos saves you nothing

Everyone has asked this once and the answer is one sentence: because those files are already compressed. A JPEG or WebP photo, an MP3 track and an MP4 video are all the product of heavy compression, and no repetition is left in them for ZIP to find.

We tried it on this server. One WebP image from the site media library, 549 KB. We compressed it with gzip at the highest setting and the result came out 115 bytes bigger than the original. Bigger, not smaller. The reason is reasonable enough: there was nothing left to collapse, and every compressed file carries a few bytes of header that get added on top.

So zipping a folder of photos is not useless, its use is simply a different one. It turns dozens of files into one file that is easier to send and does not lose pieces on the way. If your goal is less weight, you have to go at the photos themselves rather than at their packaging. That is the subject of the image formats lesson.

How much smaller does lossy actually get

Quoting a number here is meaningless except on a specific image, so we took a real one from this site media library, 2544 by 1904 pixels, and saved it several times with different settings.

As a PNG, which is lossless, it came to 7021 KB; about seven megabytes for one image. The same image as a JPEG at quality 90 came to 1388 KB, at quality 60 to 554 KB, and at quality 30 to 319 KB.

Two things in that row of numbers are worth seeing. First, the big jump happens between lossless and lossy, not between quality 90 and quality 30. Second, dropping from 60 to 30 takes only about two hundred kilobytes off and in exchange makes the damage visible along the edges. That is why in practice we usually stop somewhere between sixty and eighty and go no lower.

And one point tutorials rarely make: lower the quality once only. Every time you open a lossy file and save it again, fresh damage rides on top of the old damage. Keep the original lossless version somewhere and always export from that.

A password on an archive: a tool and a trick at once

Almost every compression program can put a password on an archive. It is a useful thing. If you have to email a few sensitive files, a password protected archive beats sending them plain, provided the password arrives by another route, a phone call for instance.

Now the other side of the coin. That same feature has been a malware delivery route for years, and the reason is not very technical. A system that inspects email attachments cannot see inside a password protected archive. Microsoft own documentation for Defender for Office 365 says exactly that: an encrypted attachment cannot be fully scanned or detonated unless the password is available, for example extracted from the email body. Which is why their recommended policy is to quarantine such messages.

So whoever sends the malware writes the password in the body of the email. It costs you nothing and it is a wall to the scanner.

The rule that follows is simple and better kept without exception: do not open a password protected archive you were not expecting, even when the sender looks familiar. A sender address can be forged; a phone call cannot.

The compression you never see

Most of the compression you benefit from day to day is not in your hands and you never hear about it. Almost every page you open in a browser arrives compressed from the server, and the browser unpacks it before showing it to you.

On this site you can measure it. At the time of writing this lesson, the rgb.ir cache layer holds 3111 ready pages on disk. Together they are 466 MB of HTML and they occupy 101 MB on disk, about 22 percent. The more interesting part is that there is no uncompressed copy in that folder at all; only the compressed version is stored, and that is what goes straight to the visitor.

And this is exactly what matters in a conversation about site speed: the same content, a fifth of the traffic. If that side of it interests you, the site speed track in this same learning section carries on from here, and if you have a site that is slow, the site speed service page shows how this is done on a real one.