Convert ZIP to XZ

Compression time is paid by one machine, once. Transfer is paid by everyone who fetches the file, every time, and on a metered bucket or a CDN it is paid in money as well as seconds. That asymmetry is the entire case for XZ, and it is why the format's summary in our registry calls it the standard for source and package downloads.

It also tells you exactly when not to bother. An archive that one colleague will open once has no economics to optimise: the seconds spent packing are the only seconds involved in the file's entire life, and gzip would have finished already. Reach for XZ when the file has an audience, a mirror, a CDN bill or a long shelf life, and leave it alone when the file has a single recipient. The same reasoning explains why distributions moved their package archives to xz years ago and why nobody bothers compressing a build artefact that lives for eleven minutes inside one pipeline.

XZ is a compressor rather than an archive. The registry records it as a stream format with one member and flags the absence of any directory structure as a known problem — there is nowhere in an `.xz` file for a name, a path or a permission bit to live.

The contents of your ZIP are therefore laid out in a TAR, which carries all of that, and XZ compresses the tarball as a single object. This is not a workaround invented for this converter; it is the arrangement the entire Unix ecosystem uses, and it is why the extension you see on every source release is `.tar.xz` rather than a bare `.xz`. It also means the two layers are doing genuinely separate jobs, which is worth remembering when you publish: replacing xz with a different compressor later changes nothing about the tar inside, so the archive's structure is not a decision you are locking in today.

The number is the story. DEFLATE, which both ZIP and gzip use, encodes a repeat as a reference to something within the last 32 KB. LZMA2 in XZ can reference something up to 64 MB back — two thousand times the distance — and it encodes those references with a range coder that costs fewer bits than DEFLATE's Huffman codes.

Where that shows is any archive whose repetition is spread out: a source tree where the same licence header opens two hundred files, a dataset of similar CSV exports, a folder of documents built from one template. Where it shows least is a ZIP of photographs or video, because the content was compressed before it was archived and there is nothing left for a longer window to find.

A large dictionary is not free at the other end. The decompressor has to keep that window in memory to resolve references into it, so the memory needed to unpack roughly tracks the dictionary the file was packed with rather than the size of the file itself.

On any desktop or server this is irrelevant. It stops being irrelevant on small hardware — a router, a microcontroller-class board, a constrained build agent — which is the one place where gzip's modest 32 KB window is an advantage rather than a limitation. If you know your archive is destined for something small, that is a reason to publish a `.tar.gz` alongside it.

They share a compression family and the registry gives both a dictionary of up to 64 MB, so on ratio there is little to choose between them. The difference is what surrounds the compressed data. 7Z is a container with its own directory of entries, its own encryption and its own checksums. XZ is a compressor wrapped around one stream.

For distribution, the stream wins on convention: every Linux and macOS box has `tar` and `xz`, and almost none has 7-Zip installed by default. For an archive you are keeping and browsing rather than publishing, 7Z is the better shape because you can list it and pull one file without unwrapping two layers. Same compression, opposite ergonomics.

Both formats verify themselves. A ZIP stores a CRC per entry, so a damaged member is caught when it is extracted. XZ carries a check over its compressed stream — CRC-32, CRC-64 or SHA-256 depending on how it was written — and refuses to hand you data that does not match.

What changes is the granularity. In a ZIP the check is per file, so one bad entry is one bad file. In an `.xz` the check covers the stream, so damage is reported for the archive as a whole and the tar inside may be unrecoverable past the damage. For anything you are publishing, an external checksum file next to the download is still worth the two lines it takes.

A gzip stream can record the original file name; an XZ stream records nothing of the sort. It is compression with a header describing the check and the filters, and no place at all for a name or a timestamp.

That puts the whole burden of describing the file on what you call it. Downloads here take your original stem plus the target extension, so `release-1.4.zip` returns as `release-1.4.xz`; renaming it to `release-1.4.tar.xz` before you publish is the difference between a download people recognise and one they have to probe. It is the single most useful thing you can do to the file after converting it.

The conversion runs on our converter rather than in your browser, so the ZIP is uploaded over an encrypted connection, unpacked with 7-Zip, tarred, compressed with xz and returned. Upload, intermediates and output are deleted when the job finishes; the scratch space is memory-backed and goes away with the container that used it.

The consequences are the free tier's 25 MB per file, a sixty-second ceiling per job, a refusal for any archive declaring more than 2 GB of unpacked content, and a clean failure rather than a hang on a password-protected ZIP. If the archive is genuinely sensitive, xz-utils and 7-Zip both do this offline on your own machine.

Projects that get this right ship two files. The `.tar.xz` is for the people who will unpack it in a shell or a script, where the smaller download is real bandwidth and the tooling has been installed since the operating system was. The ZIP stays for everyone on Windows who wants to double-click it, look inside, and never think about compression algorithms at all. Both are made from the same tree and neither is a compromise.

That is not indecision; it is two audiences with genuinely different constraints, and one file cannot serve both without penalising one of them. If you only ever ship a single artefact, ship the one your actual downloaders can open — a beautifully compressed archive nobody can unpack is a support ticket with an excellent ratio, and the bytes you saved are paid back many times over in messages asking what a `.tar.xz` is.

If the ZIP is part of a build that is meant to be reproducible, be aware that repacking is not a neutral operation. The bytes of the members are preserved exactly, but the archive around them is written fresh: entry order, timestamps and the compressor's own choices all come from the machine doing the packing rather than from the archive you uploaded. Two conversions of the same ZIP can therefore differ from each other while both being entirely correct.

That matters only if something downstream is checksumming the archive rather than its contents. Release pipelines that publish a hash next to the download should generate that hash from the file they are actually shipping, computed after the final repack, and never carried over from an earlier artefact. If byte-identical output across runs is a requirement, it belongs in a local, pinned toolchain where the compression settings are yours to fix, not in a web converter.