The GZ file (.gz, .gzip)

A GZ file is one file made smaller with gzip. report.csv becomes report.csv.gz, and decompressing it gives back exactly the original, byte for byte. Text, logs, CSV, JSON and source code often shrink to a third of their size or less; photos and videos, which are already compressed, barely shrink.

The important word is one. Unlike ZIP, gzip has no idea of folders or of several files. To compress a folder, Unix tools first bundle it into a single tar file and then gzip that, which is what a .tar.gz or .tgz file is. A .gz that isn't a .tar.gz usually holds a single log, data dump, disk image or document.

You also use gzip every day without seeing a .gz file: web servers compress pages with it on the way to your browser, which unpacks them before showing them. That's the same format, sent as a stream instead of saved as a file.

gzip was released in 1992 as a free replacement for the Unix compress program, whose LZW method was covered by patents at the time. It replaced .Z files almost everywhere.

gzip itself is a thin wrapper. The compression is done by Deflate, the same method ZIP and PNG use. It works in two passes over the data:

1. 1Find repeats (LZ77). Whenever a run of bytes already appeared in the last 32 KB, it's replaced by a reference: go back this many bytes and copy that many. Repeats further back than 32 KB can't be used.
2. 2Encode compactly (Huffman coding). Common bytes and common match lengths get short bit codes, rare ones long codes. Each block of data can carry its own code tables.

The levels -1 (fastest) to -9 (smallest) only change how hard gzip searches for matches. Any decoder reads them all at the same speed. The default is -6. On our test data -9 was nearly three times slower than -6 for a file 4% smaller; the XZ page has the full comparison with bzip2, xz, Zstandard and ZIP.

The specification says the name and comment are Latin-1 (ISO 8859-1). In practice tools write whatever bytes the file name had, usually UTF-8.

A gzip file can also hold several members, each a complete header, Deflate stream and trailer, one after the other. Decompressing gives all members' data joined together. That's why cat a.gz b.gz > both.gz works: it gives a valid file that decompresses to the two originals joined. Log rotation, parallel compressors and streaming systems all produce multi-member files.

Browsers announce which compressions they accept, for example Accept-Encoding: gzip, deflate, br, zstd. The server can then send an HTML page, stylesheet or JSON response compressed, with Content-Encoding: gzip. The browser decompresses it on arrival, and the page never exists as a .gz file anywhere. Brotli (br) usually compresses web content better, but gzip is the one every client understands.

A .gz file that you download is a different case: it should stay compressed. It's normally served as Content-Type: application/gzip with no Content-Encoding, so the browser saves the bytes as they are.

• gzip deleted my original file. That's its default: gzip file replaces file with file.gz, and gunzip does the reverse. Use -k (keep) or -c (write to standard output) to keep both.
• not in gzip format: the file doesn't start with 1F 8B. It may be already decompressed (see the note above), a plain tar file, a ZIP, or an HTML error page saved under a .gz name. file name.gz tells you what it really is.
• unexpected end of file: the file was cut short, usually by an interrupted download. Everything up to that point can often be recovered with zcat name.gz > partial, but the end is lost and can't be checked.
• gzip -l shows the wrong size. The size in the trailer wraps round at 4 GiB, and for a multi-member file gzip -l reports only the last member: it lists sample-multi-member.gz as 1,435 bytes, though it decompresses to 2,970. Use zcat name.gz | wc -c for the real size.
• decompression OK, trailing garbage ignored (or trailing zero bytes ignored): there are bytes after the last member that aren't gzip data, often zero padding from a tape or a block device. The data before them is intact.
• The file name comes out different. gunzip names the output after the .gz file, not after the name stored inside. gunzip -N uses the stored name and date.
• Can't open one line from the middle. A Deflate stream has to be decoded from the start, so gzip has no random access. Tools like zgrep and zless decompress on the fly, which works but reads the whole file.

• Linux: gunzip file.gz (or gzip -d) to decompress, gzip -k file to compress and keep the original, zcat, zless and zgrep to read and search without unpacking. If the file is a .tar.gz, see the .tgz page.
• macOS: double-click: Archive Utility decompresses it next to the original. In Terminal the same gzip and gunzip commands as Linux are built in.
• Windows: File Explorer in current Windows 11 opens .tar.gz archives, but a plain single-file .gz is most reliably opened with a free tool such as 7-Zip or PeaZip. In WSL or Git Bash, gunzip works as on Linux.
• Phone: use a file manager or archive app that supports gzip; there's no built-in way that works on every device.
• Programming: Python's gzip module, Node's zlib.gunzipSync and createGunzip, Go's compress/gzip, Java's GZIPInputStream and .NET's GZipStream all read and write it.
• Convert to another compression: decompress and recompress in one pipe, for example zcat file.gz | xz -9 > file.xz. To ZIP, decompress first and zip the result.

Decompressing a gzip file runs no code from it, and the format has nowhere to hide any. The risks are about size and about the content you get out:

• Decompression bombs. Deflate can shrink highly repetitive data by about 1,000 to 1. In our test, 1 GiB of zero bytes compressed to 1,042,069 bytes with gzip -9. A 10 MB .gz can therefore expand to around 10 GB, and nested or multi-member files multiply that. The danger is greatest for servers that decompress uploads or request bodies sent with Content-Encoding: gzip.
• Malware inside. A .gz can contain any file, including an executable or script with a misleading name. Check what came out before running anything.
• Compression and secrets on HTTPS. When a web response compresses secret tokens together with text an attacker controls, the compressed size can leak the secret byte by byte. This is the BREACH attack. Sites defend against it by not putting secrets next to reflected input, or by masking tokens on each request.