Convert RAR to XZ

RAR is technically good. It is solid, it has been maintained since 1993, it carries encryption and per-member integrity, and its recovery records are a genuinely clever feature that few competitors match. None of that is the problem. The problem is that the registry records it as proprietary and there is exactly one program in the world that can create one, which makes every long-lived RAR archive a bet on a single vendor.

That bet is fine for a download you will open next week and poor for anything being deposited, published or kept. Repositories, mirrors, funders and institutional archives increasingly say so explicitly, and the requirement is usually phrased as a format with a published specification and more than one independent implementation. XZ meets that comfortably, and `.tar.xz` is the artefact shape the Unix side of that world already expects — which is why this conversion is about convention and custody rather than about compression.

This is the unusual part of the pair. RAR is marked solid in the registry, meaning it concatenates the members into one continuous stream before compressing so that repetition between files is found rather than missed at every boundary. XZ has no choice about it — it compresses exactly one stream, so its contents are inherently solid — and it does so with an LZMA2 dictionary of up to 64 MB.

Two solid compressors of a similar generation on the same data give similar answers. Expect the XZ to land within a modest margin of the RAR, sometimes a little smaller on text where the 64 MB dictionary reaches further than RAR’s, sometimes a little larger. If you were hoping for a dramatic saving, this is not the conversion that gives one; if you were afraid of a dramatic penalty for leaving a proprietary format, this is the reassurance that there is not one.

Every other archive on this site goes through 7-Zip, and RAR does not, because Debian builds 7-Zip without the RAR codec. A separate program handles it: `unrar-free`, GPL-licensed and in Debian’s main archive, run as its own process with the archive path passed after a `--` so that a file name can never be interpreted as an option.

The choice was measured rather than assumed. The usual route is RARLAB’s `unrar` from the non-free section, and the free extractor turned out to handle a real RAR5 archive rather than being limited to RAR4 as its reputation suggests. That matters for an archival reader in particular: the tool doing the reading is itself free software with published source, which is one fewer single point of failure in a chain that is supposed to outlast all of its components.

A RAR is a container: it records a name, a path, a size and a checksum for every member inside the archive itself, which is why an archiver can list one instantly. XZ records none of that. It compresses one anonymous stream, stores an integrity check over it, and the registry lists the absence of directory structure as a known problem for the format.

So the conversion unpacks the RAR, collects everything into a fresh TAR — 512-byte header per member, with fields for the name, path, mode, owner and timestamps — and compresses that tarball with xz. The tarball is built from inside the extracted directory, so your files sit at the top level rather than inside a wrapper folder. For a deposit that is the right shape: the TAR is the layer a future reader will parse, it is documented as POSIX.1-2001 ustar, and it has been stable since 1979.

The point of preferring an open format for archival is not ideology, it is arithmetic about failure. A format with a published specification can be re-implemented by anyone who needs to; a format with one vendor and a licence that forbids compatible packers cannot. The registry’s `openness` field says `proprietary` for RAR and `open` for XZ, and that single word is the difference between "we can write a reader if we have to" and "we hope they are still selling it".

Reach follows from the same property. `xz` is a base-install dependency on every mainstream Linux distribution because the package manager itself uses it; GNU tar has understood `-J` since 1.22; 7-Zip and Keka read it on Windows and macOS. WinRAR is a paid product on Windows and 7-Zip can read RAR only where the codec was built in — as this site’s own build demonstrates, that is not something to take for granted.

Three things are dropped and each is worth checking before you commit. Recovery records go first: WinRAR can embed redundancy so a damaged archive repairs itself, and XZ has no such concept. Encryption goes second — RAR encrypts and XZ does not, so a protected archive cannot be carried across even in principle. Archive comments go third, quietly, and if the comment was the only note about the provenance of a set of files, that is a real loss for a deposit.

The per-member checksum is the fourth and the most consequential. A RAR knows which member is damaged; a `.tar.xz` can only tell you that the stream is damaged, because at that layer there are no members. If integrity over decades is part of the requirement, the answer is not a better compressor — it is a manifest of hashes alongside the archive, a second copy, and storage that verifies what it returns. Write the manifest before you delete the RAR, while both are in front of you.

A password-protected RAR fails with a message rather than hanging. The extractor is invoked so that an encrypted archive reports the refusal immediately instead of waiting for a prompt on a terminal that is not attached, which is the behaviour you want from a service: a sentence rather than a timeout. Decrypt it locally with WinRAR or 7-Zip and convert the plain archive.

A multi-volume set — `part1.rar`, `part2.rar` and the rest — cannot be handled either, because reassembly needs every part present at once and this converter takes one file per job. Join the volumes on your own machine first. Both of these are common in exactly the archives people are now trying to retire, since splitting and passwording were normal practice in the era when RAR was the default, so it is worth checking the whole collection for them before planning a bulk migration.

On our server rather than in your browser. Most tools on this site convert on your own device and say so plainly; this pair cannot, because it needs both a RAR extractor and xz as real programs. The file travels over an encrypted connection to a container that runs them, and the container has no outbound internet access of its own.

Every job gets a scratch directory on a memory-backed filesystem which is deleted the moment the job ends whatever the outcome, and any job still running after sixty seconds is killed. That ceiling is closer here than on most pairs, because xz compression is slow by design — searching a 64 MB dictionary is expensive work. The free tier accepts 25 MB per uploaded file, and the archive is refused before extraction if its own listing declares an expansion above 2 GB.

A deposit is judged partly on its documentation, and this is the moment to write it. Note the original RAR file name, its size, its checksum and the date, and record that the contents were repacked as `.tar.xz` without alteration. That paragraph is what tells a future reader — or a future you — that a difference between a catalogue entry and the file on disk is a repack rather than a substitution.

Then verify before deleting anything. `tar tJf` on the result, compared entry for entry against the RAR listing: same count, same paths, same sizes. This is a lossless repack, so a mismatch is never damaged data, it is a structural surprise, and the top level is where it will be. Once the listings agree and the manifest of hashes is written beside the archive, the RAR has nothing left to do and the proprietary dependency is gone from the collection.