Convert TAR to ZIP

Tarballs that are not compressed are almost always machine output. `docker save` writes one. Backup tooling and hosting panels write them as an intermediate. Datasets get dumped as a tar because the pipeline that made them was going to compress it later and did not. Build systems produce them as an artefact to hand to the next stage.

That matters because it tells you what to expect inside: many files, machine-generated names, deep paths and no thought at all given to the archive as something a person will one day open. This conversion is usually the moment a machine's output becomes a human's file, which is a genuinely different job from repacking an archive somebody assembled on purpose. It also explains why the tarball is uncompressed in the first place — the program that wrote it was going to hand it straight to something else, and compressing an artefact that travels four inches would have been wasted effort.

Most archive conversions here trade one compressor for another and the size moves a little in one direction or the other. This one starts from nothing. TAR's compression, in our registry, is recorded as none — it writes headers and file contents in sequence and never touches a byte of them.

So a ZIP of the same content is compressed where the TAR was not, and on the material tarballs usually hold — source files, JSON, logs, configuration, container layers full of text — the difference is large rather than marginal. It is the rare conversion where the compatibility gain and the size gain point in the same direction, which is why it needs no argument for or against: there is no trade being made here beyond the loss of the Unix metadata described further down. Every other archive pair on this site asks you to give something up in exchange for something else, and this one mostly does not.

TAR is a stream of fixed 512-byte blocks and nothing else. Every member costs one header block carrying its name, size, mode and timestamp, plus its content padded up to the next multiple of 512, and the whole archive is terminated by two blocks of zeros. There is no index and no central directory anywhere in the file.

On an archive of a few large files that overhead is invisible. On one holding thousands of small ones — a `node_modules`, a checkout, a directory of tiny JSON documents — the padding alone can be a serious fraction of the file. A ZIP has per-entry overhead too, but it is tens of bytes rather than a rounding up to half a kilobyte, and the entries are compressed on top.

ZIP writes a central directory at the end listing every entry and where it starts. A program can therefore read the contents of a large archive without decompressing any of it, and pull one file out without touching the others. That is what makes a ZIP behave like a folder in Explorer.

A TAR has no index at all, so listing it means reading it from the beginning, and extracting one file from the middle means walking past everything before it. That design is a consequence of the format's age and purpose — it was written in 1979 for tape drives, where seeking backwards was not on the table — and it is why every tool that browses archives is happier with a ZIP.

A TAR stores a mode, a user and a group for each member, and that is why deployment and packaging workflows use it. ZIP has no place for any of that which desktop tools honour, so it does not come through the conversion.

The general rule across archive pairs here is that the members come out byte for byte and what the container knew about them is what is at risk — a password, and on some formats the permissions and timestamps. For a tarball this is the part to think about, because a tar from a build or a container export is far more likely to depend on an executable bit than a ZIP somebody made on a desktop.

The size gain described above is not automatic. If the tarball holds photographs, video, PDFs or files that were themselves compressed before being archived, DEFLATE has almost nothing to find and the ZIP lands close to the TAR minus its padding.

That is worth checking before you assume the conversion will solve a transfer problem. A 25 MB tar of JPEGs will not become a 6 MB ZIP, and no compressor on this site or anywhere else will make it one; the bytes were spent when the photographs were encoded. What you still get is a single file that every machine can open, which is very often the actual reason to convert in the first place.

This pair runs on our converter rather than in the browser. The TAR is uploaded over an encrypted connection, extracted with 7-Zip into a scratch directory, packed again as a ZIP from inside that directory, and returned; the upload and every intermediate are deleted when the job ends.

The scratch space is a bounded memory-backed filesystem, discarded together with the container that ran the job. The limits are 25 MB per upload on the free tier and a hard sixty-second cap per job, with an outright refusal for any archive declaring it unpacks to more than 2 GB. A tar is uncompressed, so that declaration is rarely far from the file size itself.

If the destination is a Linux machine rather than a desktop, converting to ZIP solves a problem you do not have. The idiomatic move is to keep the TAR and compress it — converting the tarball to GZ produces the `.tar.gz` that every Unix tool unwraps in one command, and keeps the modes and ownership the tar was carrying.

Pick ZIP when a person on Windows or macOS has to open the file, or when an upload form insists. Pick a compressed tarball when the file is going back into tooling. The difference is not technical taste; it is who is at the other end.

The ZIP gains a check the tarball never had. Tar’s `chksum` field covers the header block and nothing else, so a corrupted member extracts silently with the wrong bytes in it; ZIP stores a CRC-32 per entry and reports the bad one by name. Every member is copied without being re-encoded — a lossless container has nothing to re-encode in the first place. The entry count and the paths in the ZIP should match the tarball exactly, and any archiver will list both without extracting anything, which makes the comparison a thirty-second job.

The one thing worth a deliberate glance is the top level. A tar written from a parent directory carries a leading folder in every path and one written from inside does not, and the ZIP faithfully reproduces whichever it found. If your files come out one level deeper than you expected, that is the tarball's own layout showing through rather than something the conversion introduced — and it is worth knowing before a script that hard-codes the path runs against it.

A tar produced by `docker save` is a good example of an archive that is not really a folder. It holds layer blobs, a manifest and JSON metadata whose names are long hexadecimal strings, and none of it is meant to be read by a person. Converting it to ZIP works perfectly well and gives you exactly that structure, compressed, in a file your machine will open.

What it does not give you is the image. Rebuilding one needs the tar fed back into a container runtime, which expects the tar and not a ZIP, so a converted copy is useful for inspecting or forwarding the artefact and not for restoring it. The same caution applies to backup tools that write tarballs with their own index files inside: the archive converts cleanly, and whether the tool that made it will accept the converted version is a separate question worth checking before you discard the original.