Convert TAR.XZ to TAR Online (Undoing the Second Half of a Two-Step Package Build)

Why the Full Extension Already Answers Half the Question

When a file is specifically named with the complete ".tar.xz" extension rather than a bare ".xz," that naming already confirms a tar archive is inside — the question of whether a single file or a bundled archive is being compressed, which matters for plain .xz files, doesn't apply here at all. That certainty simplifies this conversion down to one purely mechanical step: removing the LZMA2 compression layer that xz applied, using its container format whose first stable specification the Tukaani project released in December 2008, and recovering the plain tar stream that was sitting underneath the whole time.

Nothing about the archive's internal file list, folder structure, or Unix permission bits changes during that removal, since xz's compression operates purely on the finished byte stream tar produced, with no awareness of what that stream actually represents. GNU tar's -J flag, or its -a auto-detection option, performs the decompression and extraction together in one command, while a plain xz -d invocation on the compressed file alone recovers just the intermediate .tar file without extracting it any further.

This is exactly the reverse of what building a .tar.xz release involves in the first place: package maintainers and release engineers run tar first to bundle a source tree or set of build artifacts, then run xz second to shrink the result before publishing it, and reversing that second step back to plain .tar is functionally identical to what a build pipeline does internally right before recompressing an already-built tarball with a different tool or setting.

What Removing LZMA2 Costs in Concrete Storage Terms

XZ Utils' own preset documentation shows exactly how much size reduction is being given up by this conversion, since the preset level used to build the original .tar.xz file directly determined how much smaller it was than the plain tar underneath. At the default preset, level 6, using an 8 MiB dictionary, compression typically shrinks source-code-style tarballs substantially; at level 9, using a 64 MiB dictionary, the reduction is generally larger still, though at the cost of roughly 674 MiB of memory during the original compression step — a number that has no bearing on this specific decompression step, since decompression memory tracks the dictionary size alone, around 65 MiB at level 9, regardless of preset.

That asymmetry matters directly for anyone reversing this conversion on constrained hardware: decompressing even a maximally-compressed .tar.xz file built at preset 9 needs only about 65 MiB of memory, dramatically less than the roughly 674 MiB the original compression required, which is precisely why extracting a .tar.xz archive is realistic on modest hardware even when building one at the highest setting wasn't.

The plain .tar file recovered by this conversion will, by definition, be larger than the .tar.xz it came from — often substantially so for text-heavy or source-code-heavy content, where LZMA2's wide dictionary window finds the most repetition to compress away. This is expected, not a sign anything went wrong; the size difference is simply the compression that was removed becoming visible again as uncompressed bytes.

What Comes Back and What's Left Behind

• Lose — whatever size reduction the original preset level provided: the exact amount depends on which of xz's ten preset levels, 0 through 9, was used to build the file in the first place.
• Gain — a file requiring no LZMA2 decoder to open at all: plain .tar has been readable on essentially every Unix-family system since the 1980s, well before xz existed.
• Unchanged — every file, folder, and Unix permission bit inside: tar's own header structure passes through this step completely untouched, since decompression only removes the outer LZMA2 layer.
• Lose — the specific integrity check the original .xz stream carried: whichever of xz's CRC32, CRC64, or SHA-256 options was chosen during compression no longer applies once the file is plain tar.
• Gain — compatibility with tools or scripts that only recognize .tar: some older intake systems and file-type checks accept plain tar but reject unfamiliar compressed extensions outright.
• Lose — the smaller footprint for transfer or storage: a decompressed tarball takes up meaningfully more disk space and bandwidth to move than the compressed original did.

Where Reversing This Specific Compression Step Actually Comes Up

The most common documented reason for this exact conversion is an intermediate step in re-compression pipelines: build systems and package maintainers occasionally need to swap one tarball's compression method for another — say, converting a .tar.xz source release to .tar.gz for a build environment that only handles gzip — and the practical process for that always passes through a plain, uncompressed .tar file as the middle step, since neither xz nor gzip can convert directly into the other's compressed format without first returning to the uncompressed tar underneath.

A second real, documented use case involves inspecting or modifying an archive's contents before recompressing it: adding, removing, or altering files inside a tarball generally requires the archive to be in its plain, uncompressed form first, since tools that edit tar archives in place work against tar's own header structure directly and don't operate on compressed streams. Decompressing a .tar.xz file to plain .tar is the necessary first step before that kind of in-place archive editing can happen at all.

A third scenario shows up in digital preservation and long-term archival contexts, where some institutions deliberately store content in an uncompressed or minimally processed form specifically to reduce the number of algorithms a future decoder would need to correctly implement to recover the data decades later — a documented, if narrow, motivation genuinely distinct from anything about immediate storage efficiency.

The Real Cause Behind "This Extraction Used Way More Disk Space Than I Expected"

A specific, recurring complaint on system-administration forums involves running low on disk space partway through decompressing a large .tar.xz release, since the operation needs enough free space to hold both the original compressed file and the much larger plain .tar file being written out simultaneously, at least until the compressed copy is deleted afterward. The documented fix is checking available disk space against the expected uncompressed size before starting, particularly for large kernel-style source tarballs where the expansion factor can be substantial, rather than assuming the compressed file's size is a reasonable estimate of the space actually needed.

A second issue reported specifically around automated pipelines involves scripts that pipe the decompression output directly into another tool without ever writing the intermediate plain .tar file to disk at all, using a construct like piping xz's decompressed output straight into tar's own extraction step — a legitimate and often more disk-space-efficient approach, but one that fails silently if either tool in the pipe isn't actually installed on the target system, since there's no intermediate file to inspect for troubleshooting when something breaks partway through.

A third pattern involves confusing the compressed file's own reported size with the tar archive's actual uncompressed content size when planning storage for a batch of releases — since xz's compression ratio varies considerably depending on how repetitive the original data was, there's no single fixed multiplier that reliably predicts uncompressed size from compressed size across different kinds of tarballs, and the documented recommendation is testing decompression on a representative sample rather than assuming a fixed ratio applies universally.

Compressed Tarball Set Beside Its Recovered Plain Form

Questions About Reversing the Compression Half of a Tarball

Why is my recovered .tar file so much bigger than the .tar.xz I started with?
Because LZMA2 compression was genuinely shrinking the file, sometimes substantially on text-heavy data. Removing it restores the original tarball size, which is expected and not an error.

Do I need a lot of memory to decompress a .tar.xz file?
No. Even a file built at the maximum preset 9 only needs about 65 MiB of memory to decompress, far less than the roughly 674 MiB that preset needed to create in the first place.

Why would I want a plain .tar file instead of keeping it compressed?
Mostly as an intermediate step — editing files inside the archive, or recompressing it with a different tool like gzip or bzip2, both require passing through plain, uncompressed tar first.

Does this conversion change any files inside the archive?
No. Tar's file list, folder structure, and Unix permission bits pass through completely unchanged; only the outer LZMA2 compression layer is removed.

Can I skip writing the intermediate .tar file to disk entirely?
Yes, by piping xz's decompression output directly into tar's extraction step in one command, which avoids needing extra disk space for the intermediate file, though it makes troubleshooting harder if something fails partway through.