Convert RAR to GZ

RAR crosses organisational boundaries far more often than it crosses technical ones. A supplier sends one, a client uploads one, a Windows-side colleague compresses a folder with the tool they have always used, and it lands on a machine where nothing reads it — a build agent, a small VPS, a container image with a deliberately short package list.

Reading it there means adding a package for the sake of one file, which looks like a trivial decision and turns out to have a licence question attached to it. This page exists so that the decision can be postponed or avoided entirely: the archive is unpacked on our side and you receive a tarball that everything on your machine already understands, with nothing new installed and nothing new to justify. For a single delivery that is the cheapest possible route, and for a recurring one it at least buys time to make the packaging decision properly rather than under pressure.

There are two ways to read a RAR on Debian and they are not equivalent. RARLAB's own `unrar` lives in the non-free component, and plenty of organisations exclude non-free entirely by policy — so what looks like a one-line install becomes an approval request. Debian also builds 7-Zip without the RAR codec, so the tool you already have does not help.

The alternative is `unrar-free`, which is GPL-2+ and sits in main, and it is what runs here as a separate process rather than as a library linked into anything. The received wisdom that it only handles the old RAR4 format is out of date: version 0.1.3 in bookworm extracts RAR5 correctly, and that was measured against a real archive rather than assumed from the changelog. Knowing this is useful whether or not you ever use this page, because it is the difference between filing a policy exception and running an ordinary `apt install` — and the assumption in the other direction is exactly what would have cost us a non-free dependency for nothing.

RAR is a container: many members, each with a name and a path, listed by the archive itself. GZ is not. Our registry records it as a stream format with exactly one member and flags the absence of directory structure among its known problems — there is nowhere in a gzip file for a file name to live.

The bridge is TAR, which holds the names, the paths and the layout, and which gzip then compresses as a single object. This is not a workaround invented for the converter; it is the arrangement Unix has used since long before either RAR or gzip existed, and it is why the extension you are aiming for has two parts.

Expect growth. Our registry marks RAR as solid, meaning its members are compressed as one continuous stream so that repetition between files is stored once. gzip compresses the tarball as one stream too, which helps, but it does so through a 32 KB window against RAR's much longer reach.

On many similar documents the difference is obvious; on a RAR full of video or photographs it is barely visible, because that content was compressed before it was ever archived. If the file has to stay small and the destination is a Linux machine, converting to XZ instead keeps far more of the ratio at the cost of gzip's streaming behaviour.

RAR5 has been the format every recent version of WinRAR writes since 2013, and support for it here was verified rather than assumed — a real archive with nested directories and compressed content, extracted and checked.

RAR4 is the gap and this page would rather name it than imply coverage. The trial packer available for building fixtures only writes RAR5, so there was no way to produce a RAR4 file to test against. The extractor's original purpose was that very format, so it almost certainly works; if it does not, the job returns the ordinary "could not be converted" message rather than anything that looks like a crash.

Encrypted archives stop at the door. The extractor is run so that it fails immediately rather than blocking on a password prompt, which is the right behaviour for an unattended service — there is no terminal for a prompt to appear in, and a job that hangs until the timeout kills it tells you nothing useful.

Multi-volume sets are the other. RAR made splitting archives normal, and reassembling `part1`, `part2` and the rest requires every volume at once; this converter is handed a single uploaded file. Rejoin them locally, or ask the sender for one archive. Both refusals are properties of an automated pipeline rather than defects, and both are cheaper to learn here than after several uploads.

Files come back with your original stem and the target extension, so `delivery.rar` returns as `delivery.gz` even though the bytes are a gzipped tarball. Most Unix tools identify it from the content and do the right thing, but scripts that switch on the extension will not.

Rename it to `.tar.gz`, or to `.tgz` — our registry lists that as the same format spelled shorter. If the file is going into automation, do the rename before it gets there rather than adding a special case downstream, because the special case will outlive the file.

This is one of the conversions on this site that does not run in your browser, because unpacking a RAR needs a real program. The archive is uploaded over an encrypted connection, extracted with unrar-free, tarred, gzipped and returned. The upload, the intermediates and the output are deleted when the job ends, in a memory-backed working directory that is thrown away with the container.

The practical limits are 25 MB per file on the free tier, a hard sixty-second cap per job, and a refusal for any archive that declares it unpacks to more than 2 GB — checked before a byte is written to disk. Nothing about the file is retained and nobody reads it, which is the same promise the rest of the server-side pairs on this site make.

A converter is the right tool for a file, not for a habit. If RAR archives reach your systems regularly, the durable answer is to install `unrar-free` where they land and stop routing them through anything else — it is in Debian main, it needs no policy exception, and it removes both the upload step and the 25 MB ceiling from a process that will otherwise be repeated indefinitely by whoever is on duty.

The better answer, where you have any influence over the source, is to ask for a different format at the point it is created. RAR cannot be produced by anything on this site and cannot be produced by most free tooling either, so every archive that arrives in it commits somebody downstream to owning a special case forever. A ZIP or a tarball costs the sender one menu choice, and it removes the entire conversation for everyone who touches the file afterwards.

On the receiving side there is nothing to install and one command to run: `tar -xzf` takes off the gzip layer and the tar inside it in a single pass, which is the behaviour that made this shape standard in the first place. Listing it first with `tar -tzf` is worth the extra second on an archive that came from outside your organisation, because it shows every path before anything is written.

That listing is also the moment to check for paths you did not expect — absolute paths, or entries climbing out of the extraction directory. Modern tar implementations strip or refuse both by default, and an archive from an unknown sender is exactly the case those defences exist for. The archive arrived from someone else's machine in a proprietary format; a look at what it claims to contain, before it lands on yours, is a cheap habit.