What is an XZ file?

XZ is a stream format, written and read from front to back. It is used for archiving.

The extension is .xz, and the full name is XZ Archive. Both matter less than what the file can hold, which is what the rest of this page is about.

It dates from 2009.

Age is worth knowing here for one practical reason: the older a format is, the more programs have had time to learn it.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

XZ stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

XZ compresses a single stream and has no concept of a filename or a folder. That is why it is so often seen paired with TAR, which supplies the structure it lacks.

It works over 8 MB at a time: the span of data repetition has to fall inside before it can be compressed away.

That single number explains most of the difference between one archive format and another. A larger span finds more repetition and takes longer and more memory to do it, which is the whole trade.

XZ carries a checksum, so a damaged file is detected rather than silently mis-read.

A checksum will not repair anything. It tells you the file is wrong, which is the difference between finding out now and finding out from whoever you sent it to.

xz, 7-Zip and Keka read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

XZ is meant to be handed over rather than worked in. Editing one is possible and rarely pleasant; the sane approach is to change the source and export again.

The recurring complaints: it holds one stream and cannot describe a folder.

None of these is a reason to avoid the format. They are the things worth knowing before you are surprised by one, which is a different claim and a more useful one.

This is the whole distinction from 7z and it explains everything else. An xz file holds exactly one compressed stream. It has no directory, no list of names, no notion of several files. Compress `report.txt` and you get `report.txt.xz`; there is nothing else in it.

That is why `.tar.xz` is the normal form. Tar bundles the directory tree into one stream and xz compresses that stream, which is the same division of labour as `.tar.gz`. A `.7z` needs no tar because 7z is itself an archive format, and an `.xz` needs one because it is not.

Both use LZMA2, so on the same data they produce very similar sizes. xz typically beats gzip by thirty per cent or more on text, source code and logs — the sort of margin that turns a 100 MB download into 65.

It buys that with time and memory. Compressing at the higher presets can take many times longer than gzip and can want several hundred megabytes of working memory. Decompression is fast and cheap regardless, which is the right shape for something compressed once and downloaded a great many times.

The Linux kernel is distributed as `.tar.xz`. So are most distribution package archives and a large share of source releases. The arithmetic is straightforward: a file downloaded millions of times justifies almost any amount of compression effort, since the cost is paid once and the saving is multiplied by every download.

That is also why you meet xz mainly when fetching software rather than when someone sends you a file. It is a distribution format, not a sharing format, and the difference shows in the tooling around it.

In March 2024 a backdoor was found in the xz-utils software — versions 5.6.0 and 5.6.1, tracked as CVE-2024-3094. It had been introduced deliberately by a contributor who had spent roughly two years building trust in the project, and it targeted the SSH daemon on systems where a library linked against xz was loaded into it.

It was caught by Andres Freund, a developer who noticed SSH logins taking about half a second longer than expected and followed the anomaly rather than shrugging. The affected versions were in testing branches and had barely reached stable distributions, so real-world exposure was small.

Nothing about the file format was compromised. The backdoor was in a particular release of a particular program, it did not alter how xz files are structured, and an `.xz` created before, during or after that period is an ordinary compressed stream. There is no way for a plain xz file to carry the exploit.

The lasting significance is about how open-source software is maintained rather than about compression. It remains the most consequential thing that has happened to this format, and it is worth knowing accurately rather than as a rumour that xz is unsafe.

xz stores a checksum — CRC32, CRC64 or SHA-256 — and verifies it on decompression. If a byte has changed in transit or on a failing disk, the extraction fails with an explicit error rather than producing quietly wrong output.

That is a real advantage over plain gzip, whose checking is weaker, and it is part of why distributions trust it for software delivery. It detects damage; it cannot repair it, which is the one thing RAR’s recovery record does that nothing else here offers.

Zstandard, released by Facebook in 2016, compresses nearly as well as xz at speeds close to gzip. For anything where compression time matters — package building, backups run nightly, data written continuously — that combination is difficult to argue with, and several distributions have moved their package format to it.

xz still wins on pure ratio at its highest settings, which keeps it in place for source releases and kernel archives where the file is built once. The two are not really competing for the same job.

Every Linux system handles xz from the command line. Stock macOS ships no `xz` binary — Homebrew or MacPorts supplies one — but its libarchive-backed `tar` unpacks a `.tar.xz` unaided, which covers most of what arrives. Windows has needed a utility such as 7-Zip, which reads it without difficulty. Decompressing a `.tar.xz` is two steps that most tools present as one: unwrap the compression, then unpack the tar.

Do not expect a folder from decompressing a bare `.xz`. You get exactly one file back — the thing that was compressed — because that is all the format ever held. If you expected a directory tree, the archive you wanted was the `.tar` inside.

Use it when something is compressed once and fetched many times: a release, a download, an archive going into long-term storage where every gigabyte is paid for. The extra minutes at compression time are amortised across every retrieval.

Do not use it to send a file to a person. ZIP is what their computer opens without help, and the size difference on a single transfer is rarely worth the friction of explaining what an `.xz` is and how to open it.