Convert ZIP to TAR

Nobody converts to TAR for storage. They convert because something downstream reads tarballs and nothing else: a container build context, a deployment script, an import endpoint, a piece of tooling written in 1998 and still quietly load-bearing. TAR dates from 1979 and standardises as POSIX.1-2001 ustar, which is why so much infrastructure assumes it — by the time most of that software was written, a tarball was simply what an archive was.

That makes this a compatibility conversion in the same sense that PDF is a compatibility conversion for a document. You are not improving the archive in any measurable way; you are changing which programs will accept it, and paying for that in bytes. Judge the result by whether the tool downstream stopped complaining, not by the size of the file it produced. It also means the tarball is usually disposable: once the build has consumed it or the import has run, the ZIP you started from is still the copy worth keeping, and the TAR can go.

This is the sentence most pages about this pair leave out. A ZIP applies DEFLATE to every entry it holds; a TAR applies nothing to anything. Converting one into the other therefore unpacks the compression and does not replace it, which means the output is very often several times the input.

For text-heavy content the multiplier is largest — source code, CSV exports, logs and XML all deflate well, so undoing that is expensive and the growth can be several times over. For a ZIP full of JPEGs, MP4s or PDFs the difference is small, because those were already compressed before they were archived and the ZIP was barely doing anything to begin with. It is worth predicting which case you are in before the download surprises you, particularly if the tarball has to travel anywhere afterwards: a conversion that quadruples a file is fine on a local disk and expensive over a network.

TAR is a stream of fixed 512-byte blocks. Every member gets one header block carrying its name, size, mode and timestamp, followed by its content rounded up to the next multiple of 512, and the archive ends with two blocks of zeros. There is no index, no compression table and no central directory.

The consequence shows up on archives of many tiny files. Five hundred one-kilobyte files cost at least a header and two content blocks each, so the padding alone is measurable — one reason a TAR of a source tree looks oddly large next to the ZIP it came from, independently of the compression that was removed.

TAR can record a file mode, a user and a group, which is exactly why Unix tooling likes it. What it cannot do is invent those values. They come from whatever the unpacking of your ZIP produced on our converter, not from the machine where the files originally lived.

So treat the modes in the output as unspecified rather than preserved, and set them explicitly after extracting if anything depends on them — an executable bit on a script is the usual casualty. The registry states the general form of this for every archive pair: the members come out byte for byte, and what the container held *about* them is the part at risk.

A large share of people who search for this pair actually need a compressed tarball, because that is what the instruction they were following said. If the target is a download, a release artefact or anything crossing a network, the plain TAR is the wrong half of the answer.

Converting the ZIP to GZ instead produces exactly that. Every target here that cannot hold more than one file — GZ, BZ2 and XZ — is built by making a TAR first and compressing it, which is what the `.tar.gz` convention has always meant. Ask for TAR when a tool wants a tarball; ask for GZ when a human wants a download.

Archive repacking is one of the conversions on this site that needs a real machine, so the file travels. It goes over an encrypted connection to our converter, 7-Zip unpacks the ZIP and writes the TAR, the result comes back, and both the upload and the output are deleted when the job finishes. The scratch directory lives in memory and is discarded with the container.

The limits are the ones that come with that arrangement: 25 MB per file on the free tier, and a hard stop at sixty seconds per job. Sixty seconds is generous for a repack of this size and exists because a deliberately malformed archive tends to make a compressor spin rather than fail.

Two refusals are worth knowing in advance. An archive that declares it unpacks to more than 2 GB is rejected before a single byte is written to disk, which is the guard against a ZIP built to fill a filesystem. And a ZIP that turns out to contain nothing gets a plain message rather than an empty tarball.

Encrypted ZIPs also stop here. The unpacker is deliberately given an empty password so that a protected archive fails immediately with a readable error instead of waiting on a prompt that will never be answered. Remove the password locally first and convert the plain archive.

The registry flags large files as a known problem for TAR, and the reason is in the header: the original ustar format stores a file size in a twelve-character octal field, which cannot express anything past 8 GiB, and stores names in a 100-character field with a 155-character prefix. Long paths and huge members were the two things that broke.

Modern extensions solve both, and modern tools write them by default, so most people never meet either limit. On the free tier here neither is reachable anyway — the 25 MB ceiling on the input arrives long before the format does — but it is the reason you will still find advice on the internet about splitting tarballs.

For long-term keeping, TAR has one property the compressed formats do not: damage stays local. A corrupted region in an uncompressed tarball costs you the files in that region, and everything after it can still be read, because the structure is nothing more than headers and content in sequence with no shared state between members. A tool that walks the blocks can step over the damage and carry on, and even a text editor will show you which files were involved.

A compressed archive is far less forgiving. A bad byte early in a solid stream can cost everything after it, because every later reference depends on correctly decoded earlier output. That is the honest argument for storing a plain TAR alongside a compressed copy rather than instead of one — the compressed file for moving, the uncompressed one for surviving — and it is a completely different reason to want this conversion than the tooling reason most readers arrive with.

ZIP treats packaging and compression as one operation, which is convenient and quietly removes a choice from you: the archive is deflated because that is what ZIP does, at whatever level the tool that wrote it picked. A TAR makes no such decision. It has no compression setting, no level, no dictionary and no algorithm — it records what the files are called and puts their bytes in order, and stops there.

That separation is why Unix tooling composes so freely. The same tarball can be piped into gzip for speed, xz for size or nothing at all for an intermediate step, and the choice can be made by whoever is doing the moving rather than by whoever did the packing. If you asked for a TAR because a later stage compresses its own artefacts, you have made exactly that decision on purpose, and the uncompressed output is the correct result rather than a disappointing one.