GZ File Documentation

Summary

A GZ file is a single file compressed with gzip, the standard Unix/Linux compressor, defined by RFC 1952 and using the DEFLATE algorithm. Its MIME type is application/gzip. Unlike ZIP, plain gzip holds only ONE file, so you very often see .tar.gz, where many files were first bundled into a .tar and then gzipped. Open a .gz file with 7-Zip or PeaZip on Windows, or gunzip file.gz on Linux and macOS.

Technical details

FeatureValue
Full nameGzip compressed file
File extension.gz (multi-file: .tar.gz, .tgz)
MIME typeapplication/gzip
Format typeSingle-stream compressed file
Compression algorithmDEFLATE (LZ77 + Huffman coding), CM byte = 8
DeveloperThe GNU Project (gzip by Jean-loup Gailly and Mark Adler)
Introduced1992 (gzip 1.0)
Standard / specRFC 1952 (1996), version 4.3
Open standardYes — patent-free, royalty-free
Byte orderLittle-endian (MTIME, CRC32, ISIZE)
Magic number1F 8B 08 (ID1, ID2, then CM=8) at offset 0
Header size10 bytes fixed, plus optional fields per FLG
Footer size8 bytes: CRC-32 (4) + ISIZE (4)
Integrity checkCRC-32 of the uncompressed data
Holds multiple files?No — one stream; use with tar for many files
Compression levels1 (fastest) to 9 (best); default 6
Password / encryptionNone — not supported natively
Common useSource releases, backups, logs, HTTP transfer compression
Related extensions.tar, .tgz, .zip, .bz2, .xz, .z
CategoryCompressed / archive
Specification URLrfc-editor.org/rfc/rfc1952
File signature (magic bytes)
1F 8B 08

Offset 0, 3 bytes. 1F 8B are the fixed identification bytes ID1/ID2 that mark the file as gzip; the third byte is the compression method (CM), which is 08 = DEFLATE in every real-world file. Byte 3 (after these) is the FLG flags byte, not a version number. All multi-byte fields (MTIME, CRC-32, ISIZE) are little-endian, and the last 4 bytes of the file hold ISIZE, the original size modulo 232.

What is a GZ file?

GZ is the output of gzip ("GNU zip"), the de-facto standard compression tool of the Unix and Linux world. It was first released in 1992 by the GNU Project, written by Jean-loup Gailly and Mark Adler as a patent-free replacement for the older compress utility (.Z), whose LZW algorithm was patent-encumbered. The file format is defined by RFC 1952 and uses the DEFLATE algorithm, the same core compression found in ZIP and PNG. Its MIME type is application/gzip.

The one property that defines gzip, and the source of most confusion about it, is that it compresses a single stream of data. A .gz contains exactly one file, never a folder of many. That is why on Unix the near-universal pattern is to first archive many files into one uncompressed .tar file (which preserves names, permissions and directory structure) and then gzip that into a .tar.gz or its short form .tgz. So "a gz" in the wild is most often really a tarball: source-code releases, Linux packages, server backups and log archives almost all arrive this way. The sections below take the format apart at the byte level: the fixed header, the optional metadata fields, the DEFLATE stream, and the checksum footer.

The gzip member structure

A gzip file is one or more members concatenated together (a single member is by far the usual case). Each member has the same three-part shape: a header, the DEFLATE-compressed data, and an 8-byte footer. The header is 10 fixed bytes, optionally followed by extra metadata fields whose presence is signalled by a flags byte.

+====================+
| ID1  ID2  CM  FLG  |   bytes 0-3   (1F 8B 08, then flags)
| MTIME (4 bytes)    |   bytes 4-7   modification time
| XFL  OS            |   bytes 8-9   extra-flags, source OS
+====================+
| [ optional fields per FLG: EXTRA, NAME, COMMENT, HCRC ] |
+====================+
| ...DEFLATE-compressed data...                          |
+====================+
| CRC32 (4 bytes)    |   CRC-32 of the UNCOMPRESSED data
| ISIZE (4 bytes)    |   original size mod 2^32
+====================+

Every multi-byte integer here is stored little-endian, which distinguishes gzip from big-endian formats such as PNG. This is the correction to a common misreading of the header: there is no "version number" byte. Byte 2 is the compression method and byte 3 is the flags byte, described next.

The 10-byte header, field by field

The fixed header packs the identity of the file and enough context to reconstruct the original file's name and timestamp. Each field has a specific job defined by RFC 1952.

FieldBytesMeaning
ID1, ID20–1Fixed magic 1F 8B identifying a gzip file
CM2Compression method; 08 = DEFLATE (the only value in practice)
FLG3Flag bits enabling the optional fields (see below)
MTIME4–7Modification time of the original file (Unix epoch seconds)
XFL8Extra flags: 2 = compressor used max compression, 4 = fastest
OS9Operating system the file was compressed on (3 = Unix, 0 = FAT)

The FLG byte is a set of bit flags that announce which optional metadata fields follow the fixed header: bit 0 FTEXT (the content is probably ASCII text), bit 1 FHCRC (a 2-byte header CRC-16 is present), bit 2 FEXTRA (an extra field follows), bit 3 FNAME (the original filename follows, NUL-terminated), and bit 4 FCOMMENT (a NUL-terminated comment follows). Bits 5–7 are reserved. This is how gzip file.txt can produce file.txt.gz and, on decompression, restore both the original name and its modification time: the name rides in the FNAME field and the timestamp in MTIME. MTIME is why two .gz files compressed from identical data at different times are not byte-identical.

The DEFLATE stream

The compressed payload is a raw DEFLATE stream, the algorithm specified in the companion RFC 1951. DEFLATE combines two techniques. First, LZ77 finds repeated byte sequences and replaces a repeat with a back-reference: a (length, distance) pair meaning "copy length bytes from distance bytes earlier". The sliding window that back-references can reach into is up to 32 KB, which sets a ceiling on how far apart two identical runs can be and still be de-duplicated. Second, Huffman coding assigns shorter bit codes to more frequent symbols (both literal bytes and the length/distance codes), squeezing the output further.

DEFLATE emits the data as a series of blocks, each of which can be stored uncompressed, compressed with a fixed Huffman table, or compressed with a custom Huffman table built for that block's statistics and written into the block header. Because the compressor chooses per block, it adapts to changing data. This block design is also what makes gzip streamable: a compressor can emit output as it reads input without buffering the whole file, and a decompressor can produce output before it has seen the end. The compression level (1–9, default 6) mostly tunes how hard LZ77 searches for matches, trading CPU time for a smaller result.

Each member ends with an 8-byte footer of two little-endian 32-bit values. The first is a CRC-32 checksum computed over the uncompressed data, so a decompressor can verify that what it produced matches what was compressed; a mismatch means corruption. The second is ISIZE, the size of the original uncompressed data modulo 232. Two consequences follow. Reading the last four bytes gives a quick (though truncated) size estimate without decompressing — this is what gzip -l reports. And because ISIZE is only 32 bits, it wraps for original files of 4 GB or larger, so the reported size for very large payloads is the true size modulo 4 GB, not the full value.

GZ versus tar.gz: one file versus many

Because gzip compresses a single stream, a bare .gz holds exactly one file and nothing else — no directory tree, no filenames beyond the one FNAME field, no permissions. To package many files, Unix first concatenates them into a .tar archive, which is the layer that records every file's name, size, permissions and folder structure, and then gzips that single tar file. The result is archive.tar.gz (or .tgz). This is why extracting a tarball is conceptually two steps: strip the gzip layer to recover the .tar, then unpack the .tar to get the files. On the command line tar -xzf archive.tar.gz does both in one pass (the z flag runs the gzip stage), and GUI tools like PeaZip and Keka unwrap both layers in a single extract. A single-file .gz, by contrast, has no tar inside; gunzip file.gz simply produces file.

Opening and creating GZ files

The gzip format is open and ubiquitous, so essentially every archiver supports it. On Windows, Explorer does not open .gz natively, so install the free 7-Zip or PeaZip and use right-click › Extract; both also create .gz. On macOS, the built-in Archive Utility decompresses (and untars) a .gz or .tar.gz when you double-click it, and Keka creates them with options. On Linux and Unix, gzip, gunzip and tar are pre-installed: gunzip file.gz for a single file, tar -xzf file.tar.gz for a tarball, and the desktop managers Ark, File Roller and Xarchiver handle both from a GUI. Creating a plain .gz is just gzip file, which replaces the original with file.gz.

Frequently asked questions

What is the difference between .gz and .tar.gz?

A plain .gz compresses a SINGLE file. A .tar.gz (or .tgz) is many files first bundled into one .tar archive and then gzipped — the tar layer holds the filenames and folder structure, and gzip compresses the result. That is why most Linux and source downloads are .tar.gz.

Why is my GZ file only one file when I expected many?

Because gzip compresses just one stream. Multiple files are packaged as .tar.gz: the .tar holds all the files and the .gz compresses that single tar. Extract the gzip layer to get the .tar, then extract the .tar to get the files — or use tar -xzf to do both at once.

How does gzip detect a corrupted file?

Every member ends with a CRC-32 checksum computed over the original uncompressed data. When you decompress, gzip recomputes the CRC of its output and compares it to the stored value; a mismatch reports the file as corrupt. The 4-byte ISIZE that follows also lets it check the recovered length.

References