TAR to ZIP — a build tarball repackaged for a recipient who needs ZIP
Your build produces a tarball, but a recipient or upload workflow requires ZIP. This route reads supported USTAR files in the browser and adds per-file deflate compression while rebuilding the container. Regular file names and payload bytes are kept; original metadata is replaced with defaults.
Members are deflated again; original stored sizes and compression settings are not reproduced.
Processed on your device. Files aren’t sent anywhere.
From a build tarball to an archive people can open
A tar is a sequence of member headers and payloads. The reader validates each checksum, records the payload and writes it into a ZIP directory at the end.
- Regular file names and bytes are preserved exactly.
- Directories are kept, so the tree shape survives the handoff.
- Members land in the new ZIP in tar order unless you choose sorted-by-name, which rearranges the directory without touching payloads.
- TAR header checksums validate member descriptions. TAR has no checksum covering each payload, so a changed file body can remain undetected without an external hash.
- Nothing is extracted to folders on your machine.
Compression is added, not carried over
Plain TAR stores uncompressed payloads. Deflate can reduce text-heavy data when writing ZIP, while already-compressed files may gain little or even grow. Choose level 1 for less compression effort, 6 for the default balance, or 9 when testing a smaller result is worth the extra work.
Because compression metadata is created fresh, the output has no relationship to how the tar stored its bytes. Compression settings reset on every repack.
The handoff in four answers
Does the ZIP keep the tar's dates and permissions?
Which deflate level should the receiving side get?
Is the tar uploaded to a server?
Why did a tar that opens elsewhere get rejected?
Tar variants that convert and variants that reject
USTAR is the supported shape. Extended headers and special entry types have no ZIP equivalent here, so they stop the conversion.
| Shape in the tar | Response |
|---|---|
| Regular file with a UTF-8 name | repacked as a ZIP member |
| Directory entry | repacked as a directory |
| Symlink or hardlink entry | rejected |
| PAX or GNU extended header | rejected |
| Device, FIFO or other special file | rejected |
| Absolute, traversal or duplicate path | rejected |
| Names that are neither ASCII nor valid UTF-8 name | rejected |
The handoff workflow
- Feed the .tar to the archive studio; one file per run, capped at 12 MiB.
- Set the target to ZIP and choose a deflate level; 6 is the default.
- Pick entry order if the receiving side expects alphabetical listing.
- Allow the read to complete; the limits are 200 entries and 8 MiB for one member.
- Download the .zip and send it to the colleague or tool that could not read the tar.
- Check the entry list, since dates and permissions are not part of the output.
Limits worth knowing before you start
- The shared archive policy checks 32 MiB of payload and a 60x ratio, but this input is plain TAR: its stored bytes are not decompressed. The 12 MiB input limit is normally the tighter bound.
- At most 200 entries and 8 MiB per regular file are accepted.
- Long paths may depend on PAX or GNU extensions, which this reader refuses. A path already truncated by the tool that created the TAR cannot be recovered or reliably detected.
- The ZIP uses new header defaults; source timestamps, ownership and permissions are not retained.