Tarball: the tar container format
A tarball — a file produced by tar (Tape ARchive) — is a container that bundles many files and their metadata into a single stream. The crucial fact, often misunderstood, is that tar itself does no compression: a .tar file is a concatenation of file data plus headers, at full size. When people say "tarball" they usually mean .tar.gz or .tar.xz, where tar did the bundling and a separate compressor (gzip or xz) did the shrinking.
Tar’s job is archival and preservation of metadata, not size reduction. It records each file’s name, size, permissions, timestamps, ownership, and type (including symlinks and directories), then the file’s bytes, and moves on. The de facto format for distributing source code and Linux packages, tar pairs naturally with a compressor applied to the whole bundle — and that pairing is where the solid archive idea enters.
Tar bundles, gzip shrinks
A bare .tar is uncompressed, so it is almost always piped through a compressor. The classic pairing is gzip, producing .tar.gz (read as "tar-dot-g-z" or "targzip"): tar concatenates the files and metadata into one stream, then gzip applies DEFLATE to that whole stream. Other pairings exist — .tar.xz uses LZMA, .tar.bz2 uses bzip2, .tar.zst uses zstd — but the split of responsibilities is constant: tar structures, the compressor encodes.
Because the compressor sees the entire concatenated stream rather than individual files, it can exploit redundancy *across* files — repeated headers, shared boilerplate, duplicated code. That is exactly the solid archive advantage, and it is why a .tar.gz of many similar text files often beats a .zip of the same files: classic ZIP compresses each entry independently and never sees cross-file redundancy.
How tar differs from ZIP
ZIP and tar solve overlapping problems with different designs. ZIP is a random-access format: its central directory at the end lets a reader jump straight to any entry, and each entry is compressed independently (DEFLATE or Stored). Tar is a streaming format: it lays files out sequentially with no trailing index, so extracting one file means reading up to it, but the format is trivially streamable to tape or a pipe.
The other big difference is metadata. ZIP was designed for cross-platform file exchange and flattens much Unix metadata — symbolic links, permission bits, ownership — that tar preserves natively. That is why tar (not zip) is the standard for software distribution and backups on Unix: a tarball round-trips permissions and symlinks faithfully, where a ZIP may lose or generalize them.
The streaming heritage
Tar’s name is literal: it originated as a format for writing archives to magnetic tape, where you cannot seek backwards. That heritage shapes the format to this day. Files are written one after another with headers interleaved, there is no central index, and the only way to find a file is to read forward to it. Streaming is tar’s great strength (it works on pipes, sockets, and tape where ZIP’s random access is useless) and its main weakness (no quick single-file extraction).
This is also why corruption behaves differently. A truncated ZIP usually fails to open at all because its EOCD is cut off; a truncated tar simply loses the files after the cut, because each file is self-delimited by its header. Different failure modes for different designs.
tar.gz, tar.xz, and the format landscape
The .tar.gz pairing is the lingua franca of open-source distribution, and .tar.xz (with LZMA) is common where smaller size matters, such as Linux kernel source releases. Each is a tar stream compressed as one block — a solid archive by construction. See what is a tar.gz file for the hands-on view, and the archive formats overview for how tar.gz sits alongside zip, rar, and 7z. In a browser, a tarball is parsed locally like any other archive: the bytes are decompressed and the tar stream walked entry by entry, with nothing uploaded.
Frequently asked questions
What is a tarball?
A tarball is a file produced by tar (Tape ARchive): a container that bundles many files and their metadata — name, permissions, timestamps, ownership, symlinks — into a single sequential stream. Tar itself does no compression; a bare .tar is full size. People usually mean .tar.gz or .tar.xz, where a separate compressor was applied to the tar stream.
Does tar compress files?
No. Tar only bundles files and metadata into a container; a .tar file is uncompressed. Compression is applied by a separate program to the whole tar stream — gzip for .tar.gz, xz/LZMA for .tar.xz, zstd for .tar.zst. The split is deliberate: tar structures, the compressor encodes the entire bundle as one block.
What is the difference between tar and ZIP?
ZIP is a random-access format with a central directory that lets you jump to any entry, compressing each file independently; tar is a streaming format with files laid out sequentially and no index, so you read forward to reach a file. Tar also preserves Unix metadata like permissions and symlinks that ZIP flattens, which is why tar dominates software distribution on Unix.
Why is tar combined with gzip?
Because tar does not compress, so gzip is applied to the whole tar stream to shrink it. Compressing the entire concatenated bundle lets gzip exploit redundancy across files — the solid-archive advantage — which is why a .tar.gz of many similar text files often beats a .zip of the same files, since classic ZIP compresses each entry independently.
Is tar.gz lossless?
Yes. Both tar (the container) and gzip (DEFLATE compression) are lossless, so extracting a .tar.gz reproduces the original files byte for byte, including their permissions and timestamps. Like other archive formats, the round trip can be verified with a checksum such as the CRC-32 stored per entry in a ZIP.