Convert RAR to TAR

RAR turns up from the Windows side of a working relationship: a supplier’s asset delivery, a contractor’s handover, a customer’s log bundle, a scanned-document batch from a service that has used WinRAR since 2004. It arrives somewhere that has never needed it — a Linux server, a CI job, a data-loading step, an importer that walks TAR headers because that is what everything it was written for produced.

The instinct is to install an extractor on the machine, and it is often the wrong instinct: it means a new package on every build image, a licence question to answer, and a format that nothing else in the chain understands. Converting once, to the shape the rest of the pipeline already handles, keeps the oddity at the boundary. That is a different job from making the archive smaller or from keeping it for years, and it is why this page recommends the least clever target on the site.

RAR is proprietary, from win.rar GmbH and dating to 1993, and the registry records it as readable and not writable. That is a licence position rather than an engineering one. The UnRAR source is published on terms that allow extraction and explicitly forbid using it to build a program that creates RAR archives, so a service that respects the licence can unpack a RAR and can never produce one.

The practical consequence is worth stating: this conversion is not reversible here. Once the contents are in a TAR you can compress them with gzip, bzip2 or xz, or repack them as ZIP or 7Z, and none of those routes leads back to RAR. If you need to return a RAR to whoever sent it, you need WinRAR — the only packer there is — on a machine of your own. Nothing on this site will ever fill that gap.

Every other archive on this site is handled by 7-Zip, and RAR is the exception. Debian builds 7-Zip without the RAR codec, so a separate program does the work: `unrar-free`, which is GPL-licensed, sits in Debian’s main archive, and is invoked as its own process with the archive path passed after a `--` so that a crafted file name can never be read as an option.

That was not the expected answer. The conventional route is RARLAB’s own `unrar` out of Debian’s non-free section, and it turned out to be unnecessary once the free extractor was measured against a real RAR5 archive rather than assumed to be stuck at RAR4. Recording that here is deliberate: it is the kind of detail that gets "corrected" back to the non-free package by somebody tidying up, and the measurement is the reason not to.

RAR is a solid format — the registry marks it so — which means it concatenates the members into one continuous stream before compressing, and finds repetition between files rather than restarting at every boundary. That is why a RAR of forty similar documents is small. TAR does none of it: 512-byte header, file, padding to the next 512-byte boundary, next header, and two empty blocks at the end.

So the size change is not a percentage, it is a category change. A 20 MB RAR of text-heavy material can easily become a tarball several times that, and on top of the raw contents you are paying TAR’s padding — a one-byte file occupies a full 1,024 bytes, header and data block. On a set of small files that overhead is visible on its own. Know the number before the tarball has to travel anywhere, because an archive that fitted an attachment limit comfortably will not afterwards.

A TAR header is unusually expressive for something this old: name, path, size, modification time, owner, group and permission bits, all in fixed fields. That is exactly what a Unix pipeline wants, and it is why a tarball is the right intermediate for anything that will be unpacked and then executed or served.

What the TAR receives depends on what the RAR held. An archive written on Windows by WinRAR may never have recorded a Unix mode at all, in which case the tarball gets whatever the extraction produced rather than anything meaningful. The registry’s note for this pair is blunt about it: the files come out byte for byte, and what the old container held about them rather than in them is the part at risk. If a script has to arrive executable, check it with `tar tvf` and fix it rather than assuming.

RAR carries several things TAR has no field for, and they are dropped rather than approximated. Recovery records — the redundancy WinRAR can add so a damaged archive can repair itself — do not exist in TAR and neither does per-member encryption. Comments stored in the archive go the same way. The registry gives RAR encryption and a checksum; a TAR has a header checksum and nothing else worth calling integrity.

That loss of a per-member checksum is the one to notice, because it changes what you can detect later. A RAR knows when a member is damaged; a plain TAR mostly does not, and a corrupted member unpacks quietly as corrupted data. If the tarball is going to be stored rather than consumed immediately, compress it with something that adds a stream check — gzip, bzip2 or xz all do — or record hashes of the members yourself.

A plain TAR is rarely the final state and it is a good intermediate one, because it separates two decisions that RAR bundles together. Bundling is done; compression is now yours to choose. Gzip if the artefact is fetched repeatedly by machines and should stream. XZ if it is going into storage and will be read almost never. Bzip2 if something downstream names it or the machine at the far end is very short of memory.

That separation is the whole Unix argument for `tar` plus a compressor, and it is genuinely useful when the archive is being handed on rather than opened. You can also compress once and republish in two forms, which a single-format container makes awkward. If you know now which compressor you want, this site converts a RAR straight to a gzipped or xz-compressed tarball in one step instead — the plain TAR is for when you do not, or when the next tool wants it uncompressed.

On our server, not in your browser. Most of the tools on this site convert on your own device and say so; archives are one of the exceptions, and RAR is the strongest exception of all, because reading it needs a specific extractor that no browser has any equivalent for. The file goes over an encrypted connection to a container that has no outbound internet access of its own.

Each job gets a scratch directory on a memory-backed filesystem which is deleted the moment the job finishes, successful or not, and any job still running after sixty seconds is killed. Before extraction the archive is asked what it claims to unpack to, read from unrar’s own listing, and a declared total above 2 GB is refused rather than allowed to fill a disk. The free tier accepts 25 MB per uploaded file — which on a solid RAR represents a great deal of content, and produces a much larger download.

Compare `tar tvf` on the result against what WinRAR or 7-Zip shows for the archive: same member count, same paths, same sizes. It costs seconds and it catches the failure that actually happens here, which is never corrupted data — this is a lossless repack — but a shifted top level. An archive packed from inside a directory and one packed from its parent differ by a leading folder on every path, and the tarball here is written from inside the extracted directory, so your files sit at the root.

Then look at the modes in the listing before you feed the tarball to anything that will run what it unpacks. This is the moment where a permission bit is cheap to fix and after this it is not: extract, `chmod`, re-tar, and the archive is correct for every machine that receives it afterwards. Once the listing matches and the modes look right, the RAR has done its job and the pipeline can have the tarball.