Convert XZ to TAR Online (Stripping LZMA2 Compression Back to a Raw Tarball)

What an XZ File Actually Wraps Around a Tarball

A .xz file is not an archive format in the sense that ZIP or RAR are. It is a compression container built around the LZMA2 algorithm, and by itself it does not store folder structures, multiple files, or file permissions — it only compresses one continuous stream of bytes. That stream is almost always a .tar file that was created first, then compressed second, which is why a Linux download page so often lists a file as "something.tar.xz": the .tar part built the archive structure, folders, filenames, permissions, and the .xz part came afterward purely to shrink it.

This matters directly for what "converting XZ to TAR" means in practice. There is no format translation happening the way there is between, say, a RAR archive and a ZIP archive with different internal structures. Converting XZ to TAR means decompressing the LZMA2 data and recovering the original .tar file that was compressed in the first place. The archive structure inside doesn't change at all; only the compression wrapper comes off.

It's also worth noting a .xz file doesn't have to wrap a .tar at all — it can just as easily compress a single plain text log, a disk image, or any other single stream of bytes, since XZ's job is only ever compression, never archiving multiple files together. When a download is simply named "something.xz" rather than "something.tar.xz," that's the signal that only one file was compressed, with no archive structure inside to extract afterward, and unwrapping it produces one file rather than a folder of files.

LZMA2's Dictionary-Based Compression Compared With TAR's Lack of Any

The .xz container format reached its first stable specification in December 2008, built by the Tukaani project as a successor to the older, more limited .lzma format. It uses LZMA2, an improved version of the original LZMA algorithm that added support for encoder flushing, uncompressed chunks for incompressible data, and better behavior for multithreaded compression. Inside a .xz file, data is organized into one or more independent streams, each opening with a 12-byte header carrying a fixed magic number, and each stream can be split into blocks that XZ's index structure can locate without decompressing everything before it — a form of limited random access most flat compression formats don't offer.

A .tar file has none of this. TAR — short for Tape Archive — dates to early Unix tape backup tools and stores files back-to-back with fixed-size headers describing each entry's name, permissions, and size, applying zero compression of its own. This is exactly why the two formats are so often paired: TAR handles bundling multiple files and folders together with their Unix permissions and structure intact, and XZ handles making that bundle smaller, with each format doing only the one job it was actually designed for.

The XZ Utils command-line tool also supports compression levels from 0 through 9, with an additional "extreme" variant at several levels that trades noticeably more compression time for a slightly smaller result, plus a multithreading flag that splits the input into independently compressed blocks so multiple CPU cores can work on one file at once. None of this configurability exists inside a plain .tar file, since TAR has no compression settings of any kind to configure — it only ever stores bytes exactly as it received them.

What Changes When the LZMA2 Layer Comes Off

• Lose — most of the size reduction XZ provided: XZ Utils commonly produce files noticeably smaller than the equivalent gzip output on the same data, so removing that compression brings the file back up close to its original uncompressed size.
• Gain — a file every basic archive tool can already open: plain .tar has been readable by essentially every Unix-family system since the 1980s, with no LZMA2 decoder required at all.
• Unchanged — every file, folder, and Unix permission bit inside: decompression only removes the LZMA2 wrapper; the tar archive's internal file list and structure pass through untouched.
• Lose — the CRC64 integrity check XZ carries by default: XZ's default data integrity check uses CRC64, and once decompressed to plain TAR that specific check is gone, though TAR itself never had this check to begin with.
• Gain — compatibility with tools that reject .xz outright: some older or more restrictive intake systems and legacy scripts recognize .tar but choke on unfamiliar .xz-wrapped input.

Why Kernel.org Moved Its Tarballs to XZ Instead of Gzip

The Linux kernel's own release history shows exactly why .tar.xz became so common in the first place. Kernel.org began offering .tar.xz alongside the older .tar.gz and .tar.bz2 tarballs, and by September 1, 2018, the project stopped generating anything but XZ-compressed tarballs for its main pub download locations entirely. The reasoning was concrete rather than aesthetic: a kernel source tree compressed with XZ using LZMA2 typically runs meaningfully smaller than the same tree compressed with gzip, and because the kernel project compresses each release exactly once while millions of people download it, even a modest percentage reduction on a large tarball adds up to a significant amount of saved bandwidth at that scale.

Arch Linux built its entire package manager, pacman, around .tar.xz-based .pkg.tar.xz packages for the same reason, later migrating its own default further to .zst for speed while xz remained available. The tradeoff kernel maintainers and package repositories accept in exchange for that smaller size is compression time: XZ takes noticeably longer to compress at higher settings than gzip does, but since compression happens once on a build server and decompression happens far more often on end-user machines, and XZ decompresses quickly even when compression was slow, that tradeoff makes sense specifically for one-time-build, many-time-download distribution.

This decision also carries a real cost for people with constrained hardware: XZ's higher compression levels need substantially more memory during compression than gzip does at any setting, which is part of why some embedded build systems and older machines with limited RAM specifically avoid the highest XZ presets even though they produce the smallest files, opting instead for a middle setting or falling back to gzip where memory is genuinely tight.

The 2024 Supply-Chain Incident That Made XZ Utils Itself News

Beyond the format's technical merits, XZ Utils — the software library that actually implements .xz compression on most Linux systems — became the center of a widely reported security incident in 2024. On March 29, 2024, Andres Freund, a developer working on PostgreSQL, noticed SSH logins on a system taking around 500 milliseconds instead of the usual 100 milliseconds and traced the slowdown to a deliberately planted backdoor in XZ Utils versions 5.6.0 and 5.6.1, tracked as CVE-2024-3094. The backdoor had been inserted over roughly two years by a contributor using the name Jia Tan, who had built up trust within the project before quietly modifying the build process to inject malicious code that could allow remote code execution through OpenSSH on affected systems.

The affected versions had only reached rolling-release distributions such as Debian Sid, Fedora Rawhide, openSUSE Tumbleweed, and Arch Linux, not the stable long-term-support releases of Debian, Ubuntu, or RHEL that most production servers run, which limited the real-world blast radius considerably. The incident doesn't change anything about how the .xz file format itself works technically, but it's a specific, documented, verifiable fact about the software ecosystem behind .xz files that's directly relevant to anyone relying on XZ Utils in a build pipeline, and it's the reason many system administrators paid close attention to their installed xz-utils version numbers throughout 2024.

LZMA2-Compressed Container Set Beside Plain Uncompressed Tarball

Common Questions About Unwrapping a Tar.xz Archive

Why is my extracted TAR file so much bigger than the original .tar.xz?
Because LZMA2 compression, which XZ uses, was doing real work shrinking that file. Removing it recovers the original uncompressed tar archive, which is expected to be considerably larger — that's not a sign anything went wrong.

Does converting XZ to TAR lose any files or folder structure?
No. XZ only compresses the byte stream; the tar archive's internal file list, folder paths, and Unix permission bits pass through the conversion completely unchanged.

Is the XZ Utils backdoor from 2024 something I should still worry about?
Only if you're running an affected version, 5.6.0 or 5.6.1, which mainly reached rolling-release distributions like Debian Sid or Arch rather than stable LTS systems. It has no bearing on the .xz file format itself or on files already compressed with it.

Why do Linux kernel downloads only offer .tar.xz now?
Kernel.org switched its main pub download locations to XZ-only tarballs on September 1, 2018, because XZ compresses noticeably smaller than the gzip and bzip2 options it replaced, saving real bandwidth across millions of downloads.