Convert 7Z to XZ

This is a compatibility conversion, not a compression one, and being clear about that up front saves a lot of disappointment. Someone building a package, publishing a source release or feeding a build script has a pipeline that assumes a compressed tarball: `curl … | tar xJ`, a `source=()` line in a PKGBUILD, an RPM spec with a `.tar.xz` in `Source0`, a Makefile rule that has worked for a decade. A 7Z arrived instead, usually because whoever produced it works on Windows and 7-Zip is what Windows has.

The far end will not be changed for one file. Most of the systems that expect a tarball can be taught about 7Z only by installing another tool on every machine that runs the pipeline, and that is a much larger change than converting one archive. The honest framing for this page is therefore narrow: convert if something downstream insists, and leave the 7Z alone if nothing does. There is no size argument in either direction worth acting on.

This is unusual on this site and it is why the numbers here are boring. 7Z arrived in 1999 and XZ in 2009, and both are built on the LZMA family; the registry records a 64 MB dictionary for each. A dictionary that size is what lets a compressor notice that a phrase in file forty already appeared in file three, and both formats get to notice the same things.

So the ratio is decided by the data rather than by the choice of format. On a folder of source code or logs both will find a great deal of repetition and both will find roughly the same amount of it; on a folder of JPEGs or MP4s neither will find anything, because the redundancy was removed before the files were archived. If you were hoping the conversion would shrink a download you are already unhappy with, the answer is that the compressor was never the problem.

XZ compresses exactly one stream. It has no field for a file name, no concept of a directory, and no way to say that this range of bytes was one member and that range was another. That is not a limitation somebody forgot to fix — it is the design, and it is why TAR exists alongside it.

The conversion therefore unpacks the 7Z, collects everything it held into a TAR, and compresses that TAR with xz. The archive is built from inside the extracted directory rather than one level above it, so the tarball holds your files at the top level instead of a wrapper folder containing them. The one thing to be aware of is that this is a fresh TAR written now, not a tarball the 7Z was carrying — so if the 7Z happened to contain a `.tar` as an ordinary file, that file is preserved as a file and is not unwrapped.

You get a file ending `.xz` and the honest name for it ends `.tar.xz`. Nothing breaks if you leave it — `xz -d` and `tar` both look at the bytes rather than the extension — but every human and half the automation downstream reads the extension first, and a `.xz` that turns out to hold a tarball is the kind of surprise that produces a bug report.

Rename it before you publish it. `tar xf project.tar.xz` then does both layers in one pass, which is exactly what a reader of your release notes expects; a file called `project.xz` invites `unxz project.xz` and leaves them holding a file called `project` that is really an archive. XZ stores no original file name of its own, unlike gzip, so the extension you give the file is the only label it will ever have.

A 7Z archive knows what is inside it. The names, the paths, the sizes and a checksum per entry are recorded in the archive itself, which is why an archiver can show you the contents of a 400 MB 7Z instantly without decompressing any of it. An XZ knows nothing: `xz --list` reports the number of blocks and the stream size, and that is the whole of what it can tell you.

Everything a listing of a `.tar.xz` shows you is being read out of the TAR inside, which means the stream has to be decompressed to reach it. On a small release that is a second and nobody notices; on a multi-gigabyte archive that somebody wants to peek into it is the difference between an instant answer and a coffee break. If the archive is going to be browsed rather than consumed whole, this conversion makes it worse and the 7Z should stay.

The registry lists `xz`, 7-Zip and Keka as software that reads an XZ file, and the first of those is the point: xz is part of a base install on effectively every Linux distribution and every BSD, because the package manager itself depends on it. GNU tar has understood `-J` for XZ since 1.22, so no separate step is needed. A container image with nothing in it but a shell can usually still unpack a `.tar.xz`.

7-Zip is not in that position. It is excellent and free and it is still something a person or a build image has to install, and the registry flags patchy support as a known problem for the 7Z format for exactly this reason. On a machine you control that distinction is trivial; on a build agent, a customer machine or a minimal container you did not build, it is the whole question. That asymmetry, not compression, is what this conversion is buying.

7Z supports encryption and XZ does not, so a protected archive cannot be carried across even in principle. Rather than guessing at a password or producing something half-written, the extractor is called with an empty password so that an encrypted archive fails immediately with a readable message. Unlock it with 7-Zip or Keka on your own machine and convert the plain archive.

The other refusal happens before anything is written to disk. The archive is asked what it claims to expand to, and a declared total above 2 GB is turned away — a small 7Z can honestly announce that it unpacks to terabytes, and finding that out during extraction is too late. The check is not airtight on its own, since an archive can under-report; what bounds the rest is the arrangement around it, described below.

Not into your browser. Many of the tools on this site convert on your own device and say so; repacking archives is one of the exceptions, because it needs 7-Zip and xz as real programs. The file travels over an encrypted connection to a container that runs them, and that container is configured with no outbound internet access of its own.

Each job gets its own scratch directory on a memory-backed filesystem, and the directory is removed when the job ends whatever the outcome. A job still running after sixty seconds is killed rather than left to grind, because a malformed archive tends to put a compressor in a loop instead of making it fail. The free tier accepts 25 MB per file. If the archive holds material you would not hand to a third party at all, 7-Zip and xz on your own machine do the same two steps offline.

Run `tar tJf` over the result and compare the listing against the 7Z entry for entry: same count, same paths, same sizes. It is the cheapest possible check and it catches the one failure that matters here, which is a top-level path that shifted by a directory. An archive packed from a parent directory carries a leading folder in every path and one packed from inside does not, and a build script that expected one and got the other fails in a way that takes an hour to read.

Timestamps and Unix permissions are the other thing to look at rather than assume. The files come out byte for byte — this is a lossless repack — but what the old container recorded *about* them does not always survive, and a 7Z written on Windows may never have held a Unix mode bit in the first place. If your release needs an executable to arrive executable, check it in the tarball and fix it there instead of discovering it on somebody else’s machine.