What is a GZ file?

GZ is a stream format, written and read from front to back. It is used for the web and archiving.

The extension is .gz, and the full name is Gzip Archive. Both matter less than what the file can hold, which is what the rest of this page is about.

It dates from 1992. The specification is RFC 1952.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

GZ stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

GZ compresses a single stream and has no concept of a filename or a folder. That is why it is so often seen paired with TAR, which supplies the structure it lacks.

GZ can hold a layout that lets it start playing before it has finished arriving.

That matters mostly when converting: whatever the target cannot hold is dropped, usually without a warning.

It works over 32 KB at a time: the span of data repetition has to fall inside before it can be compressed away.

That single number explains most of the difference between one archive format and another. A larger span finds more repetition and takes longer and more memory to do it, which is the whole trade.

GZ carries a checksum, so a damaged file is detected rather than silently mis-read.

A checksum will not repair anything. It tells you the file is wrong, which is the difference between finding out now and finding out from whoever you sent it to.

gzip, 7-Zip and Keka read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

GZ is meant to be handed over rather than worked in. Editing one is possible and rarely pleasant; the sane approach is to change the source and export again.

The recurring complaints: it holds one stream and cannot describe a folder.

None of these is a reason to avoid the format. They are the things worth knowing before you are surprised by one, which is a different claim and a more useful one.

Gzip compresses a single stream. It has no directory, no list of names, no concept of several files. Compress `notes.txt` and you get `notes.txt.gz`; there is nothing else in it, and decompressing gives back exactly one file.

That is why `.tar.gz` is the normal form and why the extension has two parts. Tar bundles a directory tree into one stream, gzip compresses that stream, and the chain reads right to left. If you decompress a bare `.gz` expecting a folder, you get the single file that was compressed — which is all the format ever held.

It is an HTTP response. Nearly every web server compresses HTML, CSS, JavaScript and JSON with gzip before sending it, the browser decompresses it transparently, and neither end writes a `.gz` anywhere. That happens billions of times a day and is invisible.

This is the reason gzip is everywhere and why its speed matters more than its ratio. A server compressing a response has milliseconds, not seconds — a compressor that squeezed ten per cent harder for ten times the effort would be the wrong trade at that scale, and that is precisely the trade xz makes and gzip declines.

Gzip uses DEFLATE — LZ77 matching against a 32 KB window, followed by Huffman coding. The same algorithm compresses each file inside a ZIP and every PNG image, which is why those three formats have such similar compression characteristics.

The 32 KB window is the limit that defines it. Repetition further apart than that cannot be found, which is why gzip loses substantially to xz and 7z on large files with long-range structure — and why it costs so little to run, since the search space is small by design.

Jean-loup Gailly and Mark Adler released gzip in 1992 to replace Unix `compress`, which used LZW — the algorithm Unisys held patents on and began enforcing, the same dispute that produced PNG as a replacement for GIF.

DEFLATE was designed to be unencumbered, and it was published as RFC 1951 so anyone could implement it. That decision is why it ended up inside ZIP, PNG, HTTP and countless protocols: it was the good-enough compressor nobody had to ask permission to use.

Gzip offers levels 1 to 9. Level 1 is fast and loose, 9 searches hardest, and 6 is the default. The spread between 6 and 9 is typically a couple of per cent of size for a substantial increase in time, which is a poor trade almost everywhere.

Decompression speed is essentially constant regardless of the level used, and it is fast — hundreds of megabytes a second on ordinary hardware. That asymmetry is the format’s defining characteristic: cheap to read, cheap enough to write, never remarkable at either.

The header can hold the original file name, a modification timestamp and a comment, and a CRC32 checksum of the uncompressed data sits at the end. The checksum means corruption is detected on decompression rather than producing silently wrong output.

The stored name is why decompressing sometimes produces a file called something other than what the `.gz` was named. It is also a small privacy detail worth knowing: a `.gz` can carry the original path or name even after the file has been renamed for sending.

Joining two gzip files with nothing more than a file copy produces a valid gzip file containing both, in order. Decompressors handle it without being told.

That is why log rotation, streaming pipelines and data collection systems lean on it: a process can append compressed chunks as they arrive without ever rewriting or re-reading what came before. Neither ZIP nor 7z can do that, and it is a large part of why gzip persists in infrastructure.

xz compresses roughly thirty per cent smaller on text and takes much longer, which suits a release downloaded many times. zstd matches gzip’s speed while compressing close to xz, and is displacing gzip in package formats and backup systems for exactly that reason. Brotli beats gzip on the web and every browser supports it.

Gzip’s remaining advantage is that it is present everywhere without being installed, configured or explained. That is not nothing — but for a new system rather than an existing one, zstd is usually the better default now.

When it is going to a person rather than a machine. ZIP is what a stock Windows or macOS installation opens without help, and sending a `.tar.gz` to a colleague who is not technical is quietly asking them to solve a problem.

Do not convert when it is going back to a Unix system. Repacking as ZIP discards the permissions, ownership and symbolic links tar carried, and the extracted result may not work. For a server backup or a source release, `.tar.gz` is not an obstacle to route around — it is the reason the archive functions.