Convert XZ to TAR

Removing compression sounds like the wrong direction and there are several places where it is the only direction. `docker load` reads an image from a tarball. A number of appliance, firmware and instrument importers take a `.tar` because the loader was written to walk TAR headers and nothing was added afterwards. Migration utilities that expect a specific export shape do the same. So do some content-addressed and deduplicating stores, which want the uncompressed bytes because a one-line change to one file should not rewrite the whole artefact.

There is a second reader with a different reason: someone who simply wants to look. A tarball can be inspected, diffed, walked by a script and fed to `tar --to-command` without a decompression step in front of every operation. If you are going to touch the archive twenty times in an afternoon, taking the compression off once and putting it back at the end is a reasonable way to work.

XZ arrived in 2009 and compresses a single stream with LZMA2. It has no field for a file name, no notion of a folder, and no way to record where one member ends and another begins — the registry lists the absence of directory structure as a known problem for the format, which is a fair description of a design decision rather than a defect.

TAR, from 1979 and standardised as POSIX.1-2001 ustar, is the exact complement: a 512-byte header in front of every member recording the name, the path, the size, the owner, the group, the mode and the timestamps, and no compression at all. Between them the two do the whole job, and that is why `.tar.xz` looks like a workaround and is in fact the intended arrangement. This conversion removes the outer half and hands you the inner one.

Every other archive conversion on this site has a size argument in it somewhere. This one has the opposite, and it should be planned for rather than discovered. An XZ of source code, logs or documents can expand several times over; the registry gives XZ a dictionary up to 64 MB, which is why it compressed so well in the first place and therefore why the tarball is so much larger.

The practical consequences are all about where the file has to go next. It will no longer fit an attachment limit that the XZ cleared comfortably. It will take proportionally longer to copy over a network. On a laptop with a nearly full disk, extracting a tarball and then feeding it to a tool that extracts it again means holding the contents three times at once. None of that is a reason not to do the conversion; it is a reason to know the number before you start.

This is the most important sentence on the page for anyone converting a published release. The conversion does not peel the xz layer off your file — it extracts the archive completely and writes a new TAR from the contents. The files inside are byte for byte identical, because this is a lossless repack. The tarball around them is not the upstream one.

So the SHA-256 in the release notes, the hash in a package recipe, the signature over the tarball: none of them will verify against what you download here. If verification is part of the job, do the decompression locally with `xz -d archive.tar.xz`, which touches only the outer layer and leaves the tarball exactly as its author wrote it. Use this converter when you need a tarball to exist and its exact bytes are not part of a contract — which covers inspection, importing, and most one-off work, and does not cover packaging.

A TAR header has fields for the owner, the group, the permission bits and the modification time, and for a lot of tarballs those are load-bearing: a release with an install script depends on the script arriving executable, and a container image tarball depends on rather more than that. TAR is the format that can carry all of it.

What it receives here is another question, and the registry’s note for this pair is deliberately blunt: the files come out byte for byte, and what the old container recorded about them rather than in them is the part at risk. Because the archive is unpacked to a scratch directory and re-tarred, the modes and times are whatever survived that round trip. If the tarball is going to `docker load` or into anything that runs what it unpacks, check the header fields with `tar tvf` before you rely on them.

Not every `.xz` is a compressed tarball. A single large file — a database dump, a disk image, a CSV export — is often compressed on its own, and there is no tarball anywhere in it. The converter handles both cases: it decompresses the stream, tries to unwrap an inner TAR, and when that fails keeps the single file it found.

What you get in that case is a TAR containing exactly one member, which is a slightly odd object but a perfectly valid one and usually still what the tool downstream wants. It is also a useful diagnostic: if you expected a directory of files and the result holds one, the original was never an archive, and whatever told you it was has been misinforming you. XZ stores no file name of its own, so there was nothing in the file to tell you otherwise.

Decompressing an xz stream requires a buffer scaled to the dictionary the file was written with — up to 64 MB by the registry’s figure. On the machine converting the file that is unremarkable, which is why this rarely comes up. It comes up on the far end: if the reason you are removing the compression is that some small device could not open the XZ, then this conversion is a legitimate way to hand it something it can read, at the cost of a much larger transfer.

That is a different route from recompressing to gzip or bzip2, and it is the right one when the device has plenty of storage and no compressor at all — a rescue environment, a stripped container, an importer that reads TAR headers directly and never shells out to anything. Where the device does have gzip, sending a gzipped tarball is almost always better than sending a bare one.

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

Each job gets a scratch directory on a memory-backed filesystem, deleted as soon as the job ends regardless of outcome, and killed at sixty seconds. Before anything is written the archive is asked what it claims to expand to, and a declared total above 2 GB is refused — a check that matters more here than almost anywhere, because the output of this conversion is the uncompressed size by definition. The free tier accepts 25 MB per uploaded file.

`tar tvf archive.tar` lists every member with its mode, owner, size and timestamp, and it costs nothing. Two things are worth looking at. The first is the top level: an archive packed from inside a directory and one packed from its parent differ by a leading folder on every path, and an importer that expected one and got the other fails with an error about a missing file rather than about a directory.

The second is the permission column, particularly if anything in the archive is meant to be executed. A TAR is one of the few formats that can carry a mode bit, so if it arrives wrong you can fix it — extract, `chmod`, re-tar — rather than discovering it on a machine you do not control. Once the listing looks right, the tarball is ready for whatever refused to take the compressed version.