What Is a .TAR.XZ File? (The Full-Extension Tarball Behind Kernel.org and Debian Packages)

Why the Full ".tar.xz" Spelling Shows Up on Download Pages

A .tar.xz file is two separate operations stacked into one filename. Tar bundles files, folder paths, and Unix permission bits into a single continuous stream — a design that traces back to early Unix tape-backup tools and has no compression step of its own. Xz then compresses that finished stream using LZMA2, an improved version of the LZMA algorithm released by the Tukaani project, with its first stable container specification arriving in December 2008. Some download pages shorten this to just ".xz," but the full ".tar.xz" spelling is the more precise, unambiguous form, since it states plainly that a tar archive is what's inside rather than leaving that to be inferred.

That distinction matters because .xz on its own can just as easily compress a single database dump, disk image, or log file with no archive structure at all — nothing about the .xz compression layer itself indicates whether a tarball is underneath. The full ".tar.xz" extension removes that ambiguity up front, which is one reason software repositories and package build systems that need to be unambiguous about file contents tend to use the complete four-character double extension rather than a shortened form.

Extracting one requires reversing both steps in order: an xz-aware decompressor removes the LZMA2 layer first, recovering the plain tar stream, and then a tar-aware tool reads that stream's file headers to rebuild the actual folder structure on disk. GNU tar handles both steps in one command through its -J flag, or automatically through the -a (--auto-compress) option, which inspects the filename's extension and picks the matching decompressor without the user having to specify it directly.

The Full Preset Table From Level 0 to Level 9

XZ Utils documentation publishes an exact memory table for each of its ten preset levels, and the jump between them is far larger than most compression tools expose. At level 0, the dictionary size is 256 KiB and compression uses about 3 MiB of memory. At level 3, the dictionary grows to 4 MiB using roughly 32 MiB to compress. The default level, 6, uses an 8 MiB dictionary and about 94 MiB of compression memory. At the top, level 9 uses a 64 MiB dictionary and requires around 674 MiB of memory to compress, while decompression memory usage tracks the dictionary size directly — roughly 65 MiB at level 9, regardless of how much memory the original compression step needed.

That last point is the one preset detail with the most practical consequence: decompression memory scales with dictionary size alone, not with the heavier compressor-side memory figures. A build server compressing a release at level 9 might use nearly 700 MiB doing so, but every person downloading and extracting that same release only needs the roughly 65 MiB the 64 MiB dictionary requires to decode — a deliberate asymmetry that makes sense specifically for "compress once, decompress many times" distribution, which is exactly the pattern most .tar.xz releases follow.

This table is also why choosing a lower preset is a genuinely different decision from choosing a lower gzip compression level: gzip's compression levels only trade CPU time for ratio at a fixed 32 KiB window, while an xz preset level change also resizes the dictionary itself, directly changing how much memory both compression and decompression require, not just how long compression takes.

What a .tar.xz Archive Gains and Loses Compared With Older Tarball Forms

• Gain — a smaller file than gzip or bzip2 typically produce: LZMA2's much larger dictionary window finds repetition across a wider span of a file than either older algorithm's fixed or block-limited matching can.
• Gain — multithreaded compression through independent blocks: the -T flag splits input into blocks compressed on separate CPU cores, at a small cost to ratio since cross-block matches are lost.
• Lose — the fastest possible compression time: at higher presets, xz takes noticeably longer to compress than gzip on the same data, though decompression stays comparatively fast.
• Gain — a real, if narrow, form of random access: tools built around xz's block-and-index structure, rather than plain xz itself, can locate specific blocks without decompressing everything before them.
• Unchanged — every file, folder, and Unix permission bit inside: the tar layer is untouched by whatever compression wraps around it, since xz only ever operates on the finished byte stream.
• Lose — universal baseline support older formats already have: gzip's DEFLATE algorithm is decades older and built into far more minimal or embedded environments by default than xz is.

The Recorded Dates Two Major Package Ecosystems Adopted XZ

Debian's package tooling didn't adopt xz gradually by convention — it happened on a specific, documented cutover. Discussion of switching dpkg-deb's default compressor from gzip to xz began around DebConf 2012, and the change shipped as the new default with the dpkg 1.17.0 release, meaning every .deb package's internal data.tar archive built after that point used xz rather than gzip unless a maintainer explicitly overrode it. Fedora's RPM packaging made a comparable, independently documented move years earlier: the Fedora 12 release adopted xz as the default RPM payload compression, replacing gzip for the same reason Debian eventually gave — a meaningfully smaller installed package size across an enormous number of downloads.

Fedora's relationship with xz didn't stay static after that, either. By Fedora 31, the project switched its default RPM payload compression again, this time from xz to zstd, specifically because internal testing showed zstd decompressing roughly three times faster than xz for the same payload, which matters enormously across the millions of package installs a distribution the size of Fedora handles. This is a concrete, documented example of xz's own known weakness — slower decompression relative to some newer alternatives, even though it still beats gzip and bzip2 outright — eventually being the deciding factor in a major distribution moving on to something else for one specific use case, packaging, while xz remains the standard for kernel source tarballs.

Kernel.org's own tarball history tracks a similar, separately documented timeline: XZ-compressed tarballs were offered alongside gzip and bzip2 options for years, and the project's main pub download locations stopped generating anything but XZ-compressed tarballs on September 1, 2018 — a full decade after xz's original stable specification, showing how long real-world migration to a new compression format actually takes even after the technical case for it is settled.

The Indexed Variant That Solves XZ's Random-Access Gap

A documented limitation reported repeatedly by people working with very large .tar.xz archives is that ordinary xz compression writes one large compressed block by default, meaning extracting a single small file from deep inside a multi-gigabyte tarball still requires decompressing everything before it in the stream. Pixz, a parallel, indexed xz compressor, was built specifically to address this: when its input looks like a tar archive, pixz builds an index of every file inside while compressing, and splits the output into multiple independently compressed blocks rather than xz's single continuous block, which together allow extracting one file from deep inside a large tar.xz archive without decompressing the rest of it first.

Pixz also defaults to using all available CPU cores for both compression and decompression, whereas plain xz defaults to a single core for compression and cannot parallelize decompression across cores the way pixz can, since ordinary xz's single compressed block has no internal boundaries to split decompression work across. The tradeoff pixz documentation states directly is that larger compression blocks improve the final ratio but make random access less efficient, since a bigger block still has to be decompressed in full to reach data near its end — a real, specific tuning decision anyone building large indexed archives with pixz has to make deliberately rather than relying on one default setting for every use case.

None of this changes what a plain .tar.xz file downloaded from a typical release page actually is — a single compressed stream built with ordinary xz, not pixz's indexed format — but it's a documented, real answer to the specific complaint of "why does extracting one file from this huge tarball take so long," and it shows the compression container's block structure is genuinely extensible beyond what the default xz command produces on its own.

Preset Levels 0 Through 9 Set Side by Side

Common Questions About the Full Tar.xz Extension

Is .tar.xz different from .txz or .xz on its own?
.txz is just a shortened alias for the identical .tar.xz format. Plain .xz, without a tar layer, only means a single file was compressed — it doesn't necessarily contain a bundled archive at all.

Why does my build server need so much memory to create a .tar.xz file?
Higher xz preset levels use progressively larger dictionaries, and compressor memory scales well beyond the dictionary size itself — level 9 needs roughly 674 MiB to compress, even though decompressing that same file only needs about 65 MiB.

When did major Linux package systems start using xz?
Fedora's RPM adopted xz as its default payload compression starting with Fedora 12, and Debian's dpkg-deb switched its default from gzip to xz with the 1.17.0 release, following discussion that began around DebConf 2012.

Can I extract just one file from a huge .tar.xz without decompressing the whole thing?
Not with a plain .tar.xz file compressed by ordinary xz, since it's typically one continuous block. Archives built specifically with pixz, an indexed xz variant, do support this kind of partial extraction.

Why did Fedora eventually move away from xz for packages?
Starting with Fedora 31, RPM payloads switched to zstd compression because internal testing showed it decompressing roughly three times faster than xz, which matters at the scale of package installs Fedora handles.