Convert XZ to 7Z Online (Two Different Containers, Both Built on LZMA)

Two Formats Sharing the Same Compression Algorithm

An .xz file is a compressed data stream built on LZMA2, released in 2009 by the Tukaani Project, designed by Lasse Collin, specifically to replace the older, more limited .lzma format with a container that adds magic bytes, integrity checks, and support for concatenating multiple streams. A .7z file, created by Igor Pavlov as 7-Zip's native archive format, uses the exact same LZMA2 algorithm internally by default, along with the original LZMA and several other supported compression methods.

That shared algorithm is exactly why converting between the two isn't primarily a compression-quality question the way converting from gzip to LZMA2 would be — both formats can, and often do, use identical underlying compression. The real difference is structural: .xz compresses one continuous stream, with no concept of holding multiple distinct files, while .7z is a genuine multi-file archive format with its own per-file headers, metadata, and internal directory structure, closer in spirit to ZIP than to a raw compressed stream.

The .xz container format itself was built specifically to fix shortcomings in the earlier, more limited .lzma format: it adds magic bytes so tools can reliably identify the file, supports several different integrity-check strengths from a lightweight CRC32 up to a cryptographic SHA-256 hash, and allows multiple independently compressed streams to be concatenated together within one file. None of that container-level design is really about multi-file archiving, though — it's about making a single compressed stream more robust and verifiable, which is a different goal from what 7z's archive structure is built to solve.

A Single Compressed Stream Versus a Genuine Multi-File Container

Because .xz only ever holds one compressed stream, packaging multiple files into an .xz-based archive requires combining them with tar first, producing the familiar .tar.xz extension widely used for Linux source releases and packages. A .7z file needs no such intermediate step: 7-Zip's format stores each file's own name, size, and attributes directly, with the option to apply LZMA2 across all the files together for better cross-file compression, or to compress each file separately depending on the settings chosen.

LZMA2's dictionary size is the setting with the biggest effect on both formats' compression ratio and memory needs, since the underlying algorithm is the same either way. At the highest standard xz preset, -9, the dictionary size is 64 MiB, compression at that setting needs roughly 674 MiB of memory, and decompression afterward needs about 65 MiB. 7-Zip exposes very similar dictionary-size controls in its own compression settings, meaning the same memory-versus-ratio trade-off applies whether the LZMA2 compression is wrapped in an .xz container or a .7z one.

Converting a single .xz file to .7z is comparatively simple: decompress the LZMA2 stream, then recompress that same data as a single-file 7z archive, largely a container swap around already-similar compression. Converting a .tar.xz archive to .7z is more involved, since it means fully decompressing the LZMA2 stream, reading the individual files back out of the sequential tar structure, and rebuilding them as proper individually-tracked entries inside 7z's genuine multi-file container.

What Moving From XZ to 7Z Gains and What It Doesn't Change

• Gain — native multi-file support: 7z stores multiple files directly with their own metadata, without needing a separate tar step the way .xz requires.
• Gain — AES-256 encryption: 7z supports strong encryption for file contents, and optionally file names, which the .xz container has no equivalent for at all.
• Unchanged — the core compression algorithm in most cases: both formats commonly use LZMA2, so the actual compression ratio on the same data often ends up very similar.
• Lose — some of XZ's integrity-check flexibility: .xz supports None, CRC32, CRC64, or SHA-256 as an explicit per-file setting; 7z's own integrity checking works differently and isn't configurable in exactly the same way.
• Gain — broader default desktop tool support: 7-Zip's own format is widely supported by name across Windows and macOS archive tools, sometimes more readily recognized than a bare .xz file.
• Unchanged — every file's actual content: both LZMA2 implementations are lossless, so extracted files remain identical regardless of which container stored them.

Software Support for Each Format Today

Reading .xz files is broadly supported: the xz command-line tool ships by default on nearly every Linux distribution, and 7-Zip and PeaZip both handle .xz on Windows, with macOS support available through Homebrew's xz package or third-party tools like Keka. Despite its relative youth compared with gzip or bzip2, .xz has solid current tool coverage across all three major desktop platforms.

7z enjoys similarly broad support, being the native format of 7-Zip itself, which is free for Windows, alongside PeaZip, Keka, and The Unarchiver on macOS. Neither Windows nor macOS includes native, built-in support for either .xz or .7z the way both do for ZIP, so a dedicated tool is required on both sides of this conversion regardless of direction.

Real Complaints Reported About This Specific XZ-to-7z Move

A documented complaint in file-conversion and archive-management forums involves users expecting a dramatic size reduction after converting .xz to .7z, only to find the result is nearly identical in size — a predictable outcome once it's understood that both formats commonly use the exact same LZMA2 algorithm, so the compression ratio itself generally doesn't change meaningfully unless the dictionary size or other compression settings are also adjusted during the conversion.

A second recurring issue involves converting a .tar.xz archive and losing track of Unix file permissions in the process: tar headers natively store permission bits and ownership information for every file, but 7z's own metadata handling doesn't always preserve that exact same information depending on which tool performed the conversion and which platform it ran on, which matters specifically for archives containing executable scripts moving between Unix-like systems.

A third pattern shows up around memory usage when converting a heavily compressed, high-dictionary-size .xz file: the decompression step itself can require the same roughly 65 MiB minimum memory the original file's dictionary size demands, and attempting this conversion on a memory-constrained machine can fail or run slowly at that first decompression stage, before 7-Zip's own compression settings even come into play.

A fourth complaint involves the integrity-check setting getting lost during conversion: someone who deliberately chose SHA-256 for an .xz file, specifically to have the strongest possible corruption detection, sometimes assumes that same protection carries over automatically once the data is repackaged as 7z, when in practice 7z's own internal integrity handling works differently and isn't a direct, settings-for-settings continuation of what xz offered. Anyone relying on a specific integrity guarantee should verify how the destination format actually implements it, rather than assuming equivalence across formats.

XZ's Single-Stream Container Set Beside 7-Zip's Multi-File Archive

Questions About Converting Between These Two LZMA2 Formats

Will converting my .xz file to .7z make it significantly smaller?
Usually not dramatically. Both formats commonly use the same LZMA2 algorithm, so compression ratio on the same data tends to be similar unless different compression settings are specifically applied.

Why would I convert to 7z if the compression is basically the same?
Mainly for the container features 7z adds: native multi-file support without needing tar, plus AES-256 encryption, which the bare .xz format has no equivalent for.

Do file permissions survive converting a .tar.xz archive to .7z?
Not always reliably. Tar stores Unix permission metadata natively, but 7z's handling of that same metadata can vary by tool and platform, so checking permissions after extraction is worth doing.

Why does this conversion need so much memory?
A heavily compressed .xz file with a large dictionary size needs a matching amount of memory just to decompress, often around 65 MiB at the highest presets, before recompression into 7z even begins.

Is any data lost in this conversion?
No. Both formats use lossless compression, so every file extracted from the resulting 7z archive is identical to what was originally compressed into the .xz file.

Does 7z offer the same integrity checking as XZ's SHA-256 option?
Not in the same configurable way. XZ lets you explicitly pick None, CRC32, CRC64, or SHA-256 per file; 7z handles integrity internally, and that specific setting doesn't carry over directly during conversion.