Convert XZ to ZIP

XZ is simply what upstream publishes. Source releases, distribution packages, kernel trees and whole language toolchains overwhelmingly ship as a `.tar.xz`, because the file is fetched thousands of times and built once, and every megabyte saved is a megabyte saved repeatedly. Our registry's own summary calls xz the standard for source and package downloads.

That convention was formed by and for people with a shell, where `tar -xJf` unwraps both layers in one command, nothing needs installing and the whole question never arises. Off that path it is unhelpful: Windows shows an unknown file type, macOS offers nothing useful, and the download sits in a folder being four megabytes of something. The format was chosen by people who would never meet this problem, for good reasons that do not include you, which is why the conversion exists rather than an argument about whether upstream should have published a ZIP.

XZ compresses one stream and nothing else. In our registry it is a stream format with a single member, and the absence of any directory structure is listed among its known problems — an `.xz` file has no field for a name, a path or a permission bit.

The names live in the TAR underneath: a header block for every file, its contents in sequence, no compression of its own and no index. XZ never learns that the bytes it is compressing describe files at all. Getting your directory back therefore means undoing two separate things, and doing only the first leaves you holding a `.tar` that is no more openable on Windows than the file you started with. That second file is where most people conclude something went wrong, and it is also where the conversion on this page differs from a tool that only removes the outer wrapper.

LZMA2 encodes a repeat as a reference to something up to 64 MB earlier in the stream, and it codes those references with a range coder that spends fewer bits than DEFLATE's Huffman codes. Against ZIP's 32 KB window that is roughly two thousand times the reach.

On a source tree the effect is dramatic, because the repetition is everywhere and it is spread out: the same licence header opening two hundred files, the same import lines, the same generated boilerplate, the same indentation. This is why a project's release tarball is so often a small fraction of what it unpacks to, and why the ZIP that comes back from this page will look startlingly large next to the file you uploaded. Neither number is wrong — they are two honest measurements of the same content under compressors that are two decades and three orders of magnitude apart.

Before anything is extracted, the archive is asked what it claims to contain, and a declared total above 2 GB is refused with a plain message. On most archive pairs that guard exists for deliberately malicious files and never fires on a real one.

This pair is the exception. A strong compressor applied to a large tree can put well over 2 GB of content into a file small enough to upload comfortably, so an ordinary, entirely honest source archive can be turned away. That is a deliberate limit rather than a failure: the converter has a bounded, memory-backed working directory and a sixty-second budget, and an archive of that size belongs to a local tool rather than a web service.

A great deal, relatively speaking. ZIP compresses each entry independently against a 32 KB window and writes a directory of them, so it cannot see across file boundaries at all, let alone 64 MB back. Everything the long dictionary found is paid for again.

For a reader who wants to look inside a release, that is a fair trade — the ZIP opens with no software and the size only matters while it sits in a downloads folder. For anything being stored or moved onward it is a poor trade, and the better answer is to keep the `.tar.xz` exactly as upstream published it and open it with a local tool, since nothing a stock desktop reads will compress anywhere near as hard.

Decompressing LZMA2 means holding the dictionary the file was packed with, so the memory required tracks that setting rather than the size of the compressed file. A small `.xz` written with a large dictionary is more demanding to unpack than its size suggests.

On any laptop or server this is unremarkable. It becomes real on constrained hardware — a router, a small embedded board, a memory-capped build agent — and it remains the one durable technical argument in favour of gzip's modest 32 KB window in 2026. It is also a reason some projects still publish a `.tar.gz` next to the `.tar.xz`.

Not every xz file is a tarball. A single compressed disk image, one large log, one database dump — applying xz to one file is the format used exactly as designed, with no TAR anywhere in it.

The converter reads what came out of the xz layer and tries to parse it as a TAR; when that fails, it treats the content as the one file it is and the ZIP contains that. Because xz stores no original name — like bzip2 and unlike gzip — the entry is named by the pipeline rather than by anything the archive remembered, so give the file a meaningful name before you pass it on.

This conversion happens on our server rather than in the page. The file is uploaded over an encrypted connection, decompressed, unwrapped, packed as a ZIP from inside the extracted directory and sent back, and the upload, the intermediate tar and the output are all deleted as the job ends.

The working space is memory-backed and bounded, discarded with the container that used it. Free uploads stop at 25 MB, every job is killed at sixty seconds, and password-protected archives fail with a message rather than waiting for a prompt that has nowhere to appear. Nothing about the file is kept and nobody looks at it.

If the archive is heading to a Linux machine, a build agent or a container image, converting it is a step backwards on every axis: the target already has xz installed, the ZIP is considerably larger to move, and the modes and ownership the TAR was carrying do not survive the trip into a ZIP. A source release converted to ZIP and then built will occasionally fail for exactly that reason, in a way that looks like a problem with the project rather than with the archive.

Convert when a person on a desktop has to look inside, when an upload form insists on ZIP and cannot be argued with, or when you are forwarding contents to somebody who will never install an archiver. If `.tar.xz` files reach you regularly, 7-Zip and Keka handle both layers locally with no size ceiling and no upload, and recent Windows builds include a `tar` command that does the same from a terminal. That is the better long-term answer than any converter.

Source releases are usually published with a checksum file and often with a detached signature, and both of them describe the `.tar.xz` exactly as upstream wrote it. Verify against the original download before you convert anything at all, because a repacked ZIP will not match either of them — the members are identical but the archive around them is new, written by a different tool at a different moment.

That is not a flaw in the conversion; it is what verification is for. The correct order is to check the signature on the file you fetched, satisfy yourself that it came from the project, and only then repack it for whatever needs a ZIP. Converting first and verifying afterwards produces a mismatch that looks alarming and means nothing, and it is a genuinely common way for people to conclude that a perfectly good download has been tampered with.