Convert 7Z to GZ

The far end is the reason for this conversion. A build agent fetches artefacts and untars them, a deploy script expects a payload it can pipe, a package cache keys on gzipped tarballs, a server admin will run one command and does not want to hear about installing an archiver first.

7Z is an excellent format and none of that infrastructure assumes it exists. Converting is not an admission that it is worse; it is an acknowledgement that the thing at the other end was written years ago against gzip, is depended on by a great deal else, and is not going to change to suit one archive. Arguing the point costs more than the megabytes do, and the conversion takes seconds. Where you control both ends the calculation is different, but the usual reason to be on this page is that you control exactly one of them.

GZ, defined by RFC 1952 in May 1996, compresses exactly one byte stream. Our registry records it as a stream format with a single member and lists the absence of directory structure among its known problems — no names, no paths, no permissions live anywhere in a gzip file.

7Z is the opposite in every respect: a container with its own directory of entries, its own per-entry checksums and its own encryption. Moving from one to the other therefore needs a middle step, and that step is TAR. The contents are laid out as a tarball that carries everything gzip cannot record, and gzip compresses that tarball as a single object. Nothing about the arrangement is specific to this converter — it is what `.tar.gz` has meant since before either of the formats involved was written, and it is why the tooling at the far end will recognise the result without being told anything about where it came from.

LZMA2 in a 7Z encodes a repeat as a reference to something up to 64 MB earlier and does it with a range coder. DEFLATE in gzip references the last 32 KB and codes with Huffman. Two thousand times less reach, and a less efficient encoding of what it does find.

The tar layer at least preserves the one advantage worth keeping: gzip compresses the whole tarball as a continuous stream, so repetition that crosses file boundaries is still visible to it, exactly as it was to the 7Z. What it cannot do is see far enough to use much of it. The practical outcome is a file that is clearly larger, most obviously on collections of similar text files, while on an archive of photographs or video the two land close together because neither compressor has anything left to work with.

GZ is the only archive format in our registry flagged as streaming, and that flag is the reason the entire internet runs on gzip. A gzip stream can be decompressed from the front as bytes arrive, with no need to see the end of the file first.

That is what makes `curl … | tar -xz` work, and what lets a build agent extract an artefact while it is still downloading rather than after. A 7Z cannot do it: the archive's structure has to be read before the members can be located, so the file must land somewhere complete before anything can be unpacked. For a pipeline, that difference is worth more than the megabytes it costs.

Our registry lists browser support for gzip as universal, which is true in a sense worth spelling out: browsers negotiate gzip as a transfer encoding and decompress responses invisibly. It is the same format applied to the wire rather than to a file on disk, which is also why a browser saves a `.gz` download untouched instead of quietly unpacking it for you.

The same ubiquity holds on the command line. Every Linux distribution, every macOS install and every container image built on one has gzip; the same cannot be said of xz on a minimal image, and it certainly cannot be said of 7-Zip. A deliberately empty base carries neither — Docker’s `scratch` and Google’s distroless images ship no gzip binary — which is worth checking rather than assuming. When the requirement is "must work on whatever is at the other end", that is the argument, and it is why this pair exists.

The download takes your original stem plus the target extension, so `build.7z` comes back as `build.gz` even though its contents are a gzipped tarball. Most Unix tools work that out from the bytes, and some scripts and web servers do not.

Rename it to `.tar.gz`, or to `.tgz`, which our registry lists as the same format under a shorter spelling. It costs nothing and it removes an entire class of confusion downstream — including the classic case of someone gunzipping it, finding a tar, and assuming the conversion went wrong.

Solid compression is the property that made the 7Z small and it is also the property that makes it awkward to convert. Because the members are one continuous stream, reaching any of them means decompressing what came before, so the conversion unpacks the entire archive before it writes a single byte of tar.

That is why the sixty-second job limit and the 2 GB expansion guard matter more on this pair than on, say, a tar source. A tightly packed 7Z is a small upload that can represent a very large amount of work, and the guards read what the archive claims about itself before anything is written to disk rather than discovering it halfway through.

This conversion runs on our converter rather than in the browser. The 7Z goes up over an encrypted connection, is extracted by 7-Zip, tarred, gzipped and sent back; the upload, the intermediate tarball and the output are all deleted when the job finishes, in a memory-backed working directory that is discarded with the container.

The free tier accepts 25 MB per file. Encrypted archives fail immediately with a message rather than hanging, because the extractor is deliberately given an empty password, and an archive that turns out to be empty gets a plain sentence rather than a valid but useless download.

If the tarball is going to be fetched and written to disk in full before anything touches it, gzip's streaming advantage is worth precisely nothing and its weaker ratio is a straight loss on every download. Converting the 7Z to XZ keeps the LZMA family the archive was already using, produces a much smaller file, and costs nothing at all in a workflow that was never going to pipe anything.

The trade runs the other way too, and it is worth stating rather than assuming: xz needs more memory to decompress because the decoder holds the dictionary, it is not always present on a deliberately minimal container image, and it cannot be consumed from the front of the stream. Pick gzip for pipelines and for targets you do not control, xz for downloads and releases where the file is fetched far more often than it is made. Both are built from the identical tarball here, so the decision is only ever about which wrapper goes around it.

The TAR layer records a mode, a user and a group for each member, which is why packaging tools want tarballs in the first place. What it cannot do is recover values that were never there: those fields are filled from the extraction on our converter rather than from the machine where the files were authored, so treat them as unspecified rather than preserved.

For a build artefact that is usually harmless, and for anything that will be executed it is not. A script losing its executable bit fails at run time with an error that points at the script rather than at the archive that carried it, which is a genuinely irritating hour to spend. If your pipeline depends on modes, set them in the build step after extraction rather than trusting any archive to have brought them along — that is good practice regardless of which converter produced the tarball.