Convert TAR to GZ

Plain TARs are rarer than gzipped ones and they turn up in recognisable places. `docker save` writes one. Backup scripts that were told to bundle but not to compress write one. Some NAS and tape workflows produce one because the compression happens elsewhere in the chain. And people write one by accident, because `tar cf` and `tar czf` differ by a single character and only one of them makes the file smaller.

The result is an archive that is roughly the sum of everything inside it plus a surprising amount of overhead. That is fine on a local disk and expensive everywhere else: on an upload over a slow connection, on a bucket that charges per gigabyte-month, in an email attachment limit, in a CI cache that is fetched on every build. This conversion is the one repack on this site where the answer is almost always yes, because there is no compatibility cost — `.tar.gz` is more universally understood than a bare `.tar` is.

TAR’s structure is from 1979 and it is charmingly simple: a 512-byte header describing a file, then the file itself padded up to the next 512-byte boundary, then the next header, and two blocks of zeroes at the end to mark the finish. Nothing is compressed and nothing is indexed. The format was designed for tape drives, where fixed-size blocks were the point.

The cost of that shows up on small files. A one-byte file occupies 1,024 bytes in a TAR — a full header block and a full data block. Ten thousand configuration files, source files or JSON documents averaging a few hundred bytes each carry several megabytes of headers and padding that contain no information at all. Gzip is extremely good at exactly this: long runs of zero bytes compress to almost nothing, so a great deal of the saving on a small-file archive comes from removing overhead rather than from compressing the content.

Gzip uses DEFLATE with a 32 KB history window, which is the number that decides everything about this conversion. Within any 32 KB stretch it finds repeated strings and replaces them with references, and it then Huffman-codes what is left. On prose, code, logs, XML, JSON and configuration that is a large and reliable saving.

What it misses is repetition at long range. If the same licence header appears in two hundred files spread across a 40 MB tarball, gzip compresses it two hundred separate times because it can never see two of them at once. That is the gap XZ and 7Z exist to close, and it is why they beat gzip substantially on archives of many similar files. Gzip’s answer is that it is fast, it streams, and it is installed on absolutely everything — which for a file being moved rather than stored is usually the better trade.

This is worth stating plainly because it surprises people who expect a wrapper to be applied around their existing file. The conversion unpacks the TAR you upload, then writes a new TAR from the extracted contents and compresses that with gzip. The files inside are byte for byte identical; the tarball around them is a fresh one.

Two consequences follow. First, a checksum published against the original TAR will not match anything here, because you are not holding the original TAR any more — if a hash has to verify, compress the file with `gzip` on your own machine instead, which leaves the tarball untouched. Second, what the old container recorded about its members can shift: the registry’s note for this pair says exactly that, and permissions and timestamps are the fields at risk. For a source bundle or a document archive that is irrelevant, and for a deployment artefact it is not.

A gzip stream has a header field for the original file name, which is why `gunzip backup.gz` on a Unix machine can produce a file called `backup.tar` even though nothing in the command said so. It is a small courtesy the format extends and the reason a gzipped file is slightly less anonymous than an xz or bzip2 one, both of which store no name whatsoever.

Do not rely on it for anything important. Plenty of tools write a generic name into that field, plenty of others ignore it on extraction, and a file transferred through a system that rewrites archives loses it entirely. The extension you give the download is the label that will actually be read, so make it `.tar.gz` rather than `.gz` and save the person at the other end from unwrapping a mystery.

A gzip stream is decoded from front to back with a fixed 32 KB window and no index, which sounds like a limitation and is the source of its greatest advantage. It means the archive can be consumed as it arrives: `curl https://… | tar xzf -` unpacks a download that never lands on disk, a backup can be piped straight into gzip and out to a remote host, and a log shipper can compress on the fly without knowing how much data is coming.

The registry flags this on the format itself, and it is the reason gzip has not been displaced by anything stronger in twenty years of trying. Formats with a large dictionary need memory proportional to it; formats with a central directory need the end of the file before they can list the beginning. If your tarball is going to be piped, served over HTTP, or unpacked by something small, gzip is not the compromise choice — it is the correct one.

The three are not ranked; they sit at different points on the same curve. Gzip is the fastest to compress and decompress and gives the smallest saving. XZ gives much the largest saving on text, at a large cost in compression time and in the memory needed to unpack it. BZ2 sits between them on ratio, is slow to decompress, and the registry marks it legacy.

Decide by what happens to the file next. Something that will be fetched and unpacked repeatedly, by machines you do not control, over a pipe — gzip. Something that will sit in cold storage for years and be read almost never — XZ. Something that has to match an artefact name a build system already expects — whichever that name says, and no reasoning required. Converting a tarball is cheap enough that trying two and comparing the sizes is a legitimate way to decide.

Not into your browser. Most of the tools here run on your own device and say so; archive repacking is one of the exceptions, because it needs 7-Zip and gzip as real programs. The file travels over an encrypted connection to a container that runs them and has no outbound internet access of its own.

Each job gets a scratch directory on a memory-backed filesystem which is deleted when the job ends regardless of the outcome, and anything still running after sixty seconds is killed rather than left to grind. The free tier accepts 25 MB per uploaded file, and this is the one pair where that limit bites hardest — a TAR is uncompressed, so 25 MB of TAR is 25 MB of actual content, where 25 MB of 7Z might be ten times as much.

`tar xzf archive.tar.gz` handles both layers in one pass on macOS, Linux and the BSDs, and modern Windows ships a `tar` that does the same from PowerShell or the command prompt. Graphical archivers on Windows will typically unwrap the gzip layer and leave you with a `.tar` to open again, which is the behaviour that sends people looking for a single-container format instead.

Before the original goes, compare the listing: `tar tzf` on the result against `tar tf` on the source, same count and same paths. The top level is the thing to look at, because an archive packed from inside a directory and one packed from its parent differ by a leading folder on every entry and a script that expected one and got the other fails months later for reasons nobody remembers. Once the two listings match, the uncompressed TAR has no job left.