What Is a .TAR.GZ File? (Gzip's RFC 1952 Format Explained)

A Tar Bundle Wrapped in a Formally Specified Compression Format

A .tar.gz file is a tar archive — files bundled together using 512-byte header blocks, a design tracing back to Unix's Seventh Edition in 1979 — compressed afterward with gzip. Unlike bzip2, whose format has no single formal standards document, gzip's structure is precisely defined in RFC 1952, a specification that spells out every byte of the container gzip wraps around compressed data, separate from the DEFLATE compression algorithm itself, which has its own separate specification in RFC 1951.

RFC 1952's header starts with two fixed identification bytes, ID1 and ID2 (0x1F and 0x8B), followed by a compression-method byte and a flags byte (FLG) whose individual bits control which optional fields actually appear: FTEXT (a hint that the data is text), FHCRC (a 16-bit checksum of the header itself), FEXTRA (additional vendor-specific fields), FNAME (the original filename), and FCOMMENT (a human-readable comment). A compliant gzip writer only has to get a handful of core fields right — ID1, ID2, the compression method, the final CRC-32, and the final size — and can leave everything else at documented defaults, which is why real-world gzip files vary somewhat in which optional fields they actually include.

The Documented 4 GB Limit Hiding in Gzip's Own Trailer

At the very end of every gzip stream sit two trailing fields: a CRC-32 checksum of the uncompressed data, and an ISIZE field recording that data's original size. ISIZE is only 32 bits wide, and RFC 1952 defines it as storing the uncompressed size modulo 2^32 — meaning that for any .tar.gz built from a tar stream 4 GB or larger, that field simply wraps back around toward zero and no longer reports the true original size. Tools that rely on reading ISIZE directly to display an uncompressed size or estimate a compression ratio — including gzip's own --list option — get a genuinely wrong number for anything past that threshold, a documented limitation of the format's own design, not a bug specific to any one implementation.

There's a second, related wrinkle some implementations introduce on top of the format's own limitation: certain versions of gzip treat the stored ISIZE value as a signed rather than unsigned 32-bit integer, which can produce an additional layer of confusion — a negative-looking size — on top of the modulo wraparound the specification itself already causes. The only fully reliable way to get an accurate uncompressed size for a large .tar.gz is to actually decompress it and count the resulting bytes directly, rather than trusting the trailer field at all.

None of this affects tar's own contents once decompression actually happens — the 512-byte tar headers underneath record every file's size independently of gzip's own trailer, using their own separate fields that aren't subject to the same 32-bit ceiling in the same way. The confusion this causes in practice is specifically about trusting a compressed .tar.gz file's outer gzip metadata as a shortcut for information that's only fully reliable once the tar stream itself has actually been unpacked.

What TAR.GZ's Design Gains and Where It Falls Short

• Gain — a formally specified, unambiguous container format: RFC 1952 defines gzip's header and trailer precisely, unlike some other compression formats that rely mainly on de facto convention.
• Gain — genuinely fast compression and decompression: DEFLATE's 32 KB sliding window and simpler algorithm run considerably faster than bzip2's block-sorting approach on equivalent data.
• Gain — parallel compression through pigz: a multithreaded reimplementation can spread compression across available CPU cores, producing fully standard gzip output any ordinary tool reads normally.
• Lose — accurate size reporting past 4 GB: the ISIZE trailer field's 32-bit width means it cannot represent the true uncompressed size of very large archives without wraparound.
• Lose — some compression ratio versus wider-window alternatives: bzip2's larger blocks and xz's much bigger dictionary both commonly out-compress gzip's fixed 32 KB window on repetitive content.
• Unchanged — every file, permission, and timestamp tar itself recorded: gzip compresses the tar stream without altering anything inside it.

Where TAR.GZ Sits in Real Package Distribution Today

Gzip and tar both ship by default on essentially every Linux distribution and macOS, and Windows has included a tar.exe capable of both since Windows 10 build 1803, with Windows 11's 24H2 update adding native File Explorer support for opening .tar.gz archives directly, built on the open-source libarchive project. That breadth of default availability is a real factor in why .tar.gz remains a common choice even where a tighter-compressing alternative exists — GNU software distributions, countless project release pages, and general Unix package tooling all still routinely offer it as an option specifically because gzip's decompression code is close to universally preinstalled.

Pigz, the parallel gzip implementation written by Mark Adler (one of gzip's own original authors), divides input into 128 KB chunks and compresses them across multiple CPU cores at once, with documented benchmarks showing a multi-gigabyte tar file compressing in a small fraction of the time single-threaded gzip needs on the same multi-core hardware — though pigz's own documentation is explicit that its decompression isn't parallelized to nearly the same degree, since DEFLATE decompression is inherently more sequential than compression.

Real Problems Reported Specifically Around Gzip's Own Format Quirks

A documented issue reported across several bug trackers involves a tool displaying an obviously wrong, sometimes negative, uncompressed size for a large .tar.gz file — tracing back directly to ISIZE's 32-bit width and, in some implementations, to that value being interpreted as signed rather than unsigned. The consistent, reliable fix reported in these threads is decompressing the file and counting bytes directly (for instance, piping through gzip -dc | wc -c) rather than trusting any tool's reported size for files anywhere near or beyond 4 GB.

A second recurring pattern shows up in backup and archival scripts that assume a .tar.gz's stored size is always accurate for capacity planning or verification purposes, only to have that assumption quietly fail once source data trees grow past 4 GB — a genuinely easy mistake to make since the failure is silent rather than throwing an error, and one that only becomes visible when someone actually compares the reported figure against the real extracted size.

A third documented complaint involves someone expecting pigz to meaningfully speed up decompressing an existing .tar.gz file the same way it speeds up building one, then finding decompression times barely change — pigz's own documentation addresses this directly, noting decompression parallelism is limited compared to compression, since a single DEFLATE stream's decoding is a more inherently sequential process than encoding is.

TAR.GZ's Format Fields Measured Against Its Common Alternatives

Common Questions About the TAR.GZ Format and Its Header Fields

Why does my file manager show the wrong uncompressed size for a large TAR.GZ?
Gzip's ISIZE trailer field is only 32 bits wide and stores the original size modulo 2^32, per RFC 1952 — a documented format limitation for anything 4 GB or larger, not a bug in a specific tool.

What optional fields can a gzip header actually contain?
RFC 1952 defines five optional flag bits: FTEXT (a text-data hint), FHCRC (a header checksum), FEXTRA (vendor-specific fields), FNAME (the original filename), and FCOMMENT (a comment), though a compliant writer only needs to get the core required fields right.

Is pigz worth using instead of plain gzip?
For large archives on multi-core hardware, yes for compression specifically — pigz can meaningfully cut compression time by spreading work across CPU cores, though its decompression isn't parallelized to nearly the same extent.

How can I get the real uncompressed size of a very large TAR.GZ file?
Decompress it and count the resulting bytes directly, since the stored ISIZE field cannot represent sizes at or beyond 4 GB accurately due to its fixed 32-bit width.

Do I need special software to open a .tar.gz file?
Not on Linux or macOS, where gzip and tar are preinstalled. On Windows, tar.exe (build 1803 and later) handles it from the command line, and Windows 11's 24H2 update added native File Explorer support directly.

Why is TAR.GZ still so common if bzip2 or xz compress tighter?
Speed and near-universal default availability. Gzip compresses and decompresses considerably faster than either alternative, and its decompression code is preinstalled on more systems by default than either bzip2 or xz consistently are.