Convert GZ to 7Z

The moment that brings people here is specific. A file arrives called something like `project-4.2.tar.gz`, Windows offers no obvious way to open it, an archiver is installed, and the result of unpacking is a single file called `project-4.2.tar` — which then has to be unpacked again. Nothing is broken and nothing was done wrong; that is simply what the format is. But it is a poor fit for a desktop where the expectation is that an archive is one thing you look inside.

The Unix side of the handover has no such problem, because `tar xzf` does both layers in one command and always has. This conversion exists for the other side of that handover: the analyst, the developer on Windows, the person given a server export who needs to find one configuration file in it. A 7Z is one archive with a real table of contents, and every archiver on Windows shows it as a folder you can walk into.

TAR, from 1979 and standardised as ustar in POSIX.1-1988, is a bundler with no compressor: it writes the members one after another with a header in front of each recording the name, the path, the size, the mode and the timestamps. It makes nothing smaller. GZ, defined by RFC 1952 in 1996, is the opposite: it compresses a single stream and has no field for a name, a path or a second member.

Neither is deficient. They were designed to be composed, which is why `.tar.gz` is the oldest and most durable convention in the Unix world. A 7Z, from 1999, does both jobs in one format — it has a directory of entries with names, paths and per-entry checksums, and it compresses them with LZMA2. That is the difference this conversion is buying, and it is a structural difference rather than a matter of one format being better.

The gzip stream is decompressed first, which yields exactly one thing, because that is all a gzip stream can hold. If that one thing is a TAR it is unwrapped in turn and the files inside it become the members of the 7Z. If it is an ordinary file it is kept as it is and becomes the only member.

The inner unwrap is done by forcing the tar type rather than trusting the file name, and that detail was a real bug here before it was a design note. Gzip stores the original file name in its header, so an inner tarball from a GZ arrives called `output.tar` and a name check finds it — but XZ and BZ2 store no name, so the same tarball arrived called `input` and the check missed it. The symptom was an archive containing one opaque file instead of the thirty that went in: a conversion that reports success and returns the wrong thing.

The window is the whole argument. Gzip compresses within 32 KB of history, so a licence header that appears in two hundred source files is compressed two hundred times from scratch. 7Z uses LZMA2 with a dictionary the registry records at up to 64 MB, which is large enough to hold the entire archive for most of the files people convert, so the second occurrence of anything costs almost nothing.

That is also why the saving is unpredictable rather than a fixed percentage. A source tree, a set of exports, a directory of configuration files or a documentation build shrinks a great deal. A tarball of JPEGs, MP3s or an MP4 barely moves, because the redundancy inside those files was removed by their own codecs before the archiving started. Look at the number on your own file rather than at any figure quoted on a page like this one.

This is the practical benefit people actually feel, and it is separate from size. A 7Z records its entries in the archive itself, so an archiver can show you every path and size in a 500 MB file in the time it takes to read a few kilobytes from the end of it. That is why double-clicking a 7Z opens a window immediately.

A gzipped tarball cannot do that at all. The names live in the TAR, the TAR is inside the compressed stream, and the stream must be decompressed from the beginning to reach them — there is no index and there is nowhere to put one. Anything that appears to list a `.tar.gz` quickly is reading the whole thing and discarding it. For an archive you intend to search rather than consume whole, that single property is worth more than the compression ratio.

A TAR header records the owner, the group, the permission bits and the modification time of every member, and for a lot of tarballs that is not incidental — a release with a build script in it depends on the script arriving executable. The registry’s note on this pair is deliberately unflattering: the files come out byte for byte, and what the old container held *about* them rather than in them is what may not survive.

So if the tarball is a deployment artefact, a container export or anything that will be unpacked on a Unix machine and then run, converting it to 7Z is a change you have to test rather than assume. If it is a set of documents, a dataset, a photo collection or a source tree you are going to read on Windows, none of it matters and the conversion costs you nothing you were using.

The registry lists patchy support as a known problem for 7Z and it is the honest counterweight to everything above. Windows Explorer opens a ZIP with nothing installed and does not open a 7Z; the macOS Finder is the same. 7-Zip, Keka and PeaZip all handle it and all have to be installed first.

That makes 7Z an excellent format for an archive you are keeping and a poor one for an archive you are sending. If the point of this conversion is to make a file easier for you to work with on your own machine, it is the right target. If you are converting so that you can forward the result to somebody else, ZIP is the answer instead — it is the one archive format that opens everywhere without a conversation about which tool to install.

This conversion runs on our server rather than in your browser. Most tools on this site keep the file on your device and say so plainly; archives are one of the exceptions, because the work needs 7-Zip as a real program. The file travels over an encrypted connection to a container that has no outbound internet access of its own.

The job gets a scratch directory on a memory-backed filesystem, which is deleted the moment the job ends whatever the outcome, and it is killed after sixty seconds rather than allowed to grind. Before anything is extracted the archive is asked what it claims to unpack to, and a declared total above 2 GB is refused — a strongly compressed tarball is exactly the shape of file that can honestly announce a very large expansion.

Open the result and compare the entry list before deleting anything. The count and the paths are what matter: this is a lossless repack, so a mismatch is never a corrupted file, it is a structural surprise — most often a leading directory that is present in one and absent in the other. The archive here is packed from inside the extracted directory, so your files sit at the root of the 7Z rather than inside a wrapper folder.

7-Zip has a test command that verifies every entry against its stored checksum without writing anything to disk, and it is worth thirty seconds on any archive you intend to keep. The one case to look at more carefully is a `.gz` that held a single file: the 7Z will contain that one file, correctly, and if you were expecting a directory then the original was never a tarball and the conversion has told you something useful about it.