ZIP to TAR — turning a Zip bundle into a tarball a tar-only tool can read
A ZIP export and a tarball carry the same idea — a bundle of files and folders — but a build step, packaging tool or tar-based pipeline often reads only tar. This route decompresses each ZIP member and writes it into a USTAR tar. Nothing is uploaded and no server unpacks anything: the archive is read entry by entry inside the browser tab, so the job is a container translation, not a compression decision.
tar stores members uncompressed, so a compressed source may grow substantially.
Processed on your device. Files aren’t sent anywhere.
What the repack actually does
The reader validates the ZIP directory and each member CRC, then writes the uncompressed payload into a USTAR member. The result is an uncompressed container: payload bytes are retained, while the new headers use default metadata values.
- Regular file names and bytes are preserved exactly, byte for byte.
- Directories are kept as directory entries, so the folder shape survives.
- Entry order follows the archive by default; a sorted-by-name option is exposed.
- ZIP CRCs are validated during reading, so a corrupt member fails instead of producing a truncated file.
- Original timestamps, permissions, owners, archive comments and extra fields are not preserved; the new TAR headers use fresh defaults.
Archive features that convert, and features that reject
This USTAR writer handles regular files and directory records within fixed byte fields. Unsupported ZIP features or names that the destination cannot represent stop the entire conversion; no partially filtered bundle is returned.
| Feature in the ZIP | Response | Reason |
|---|---|---|
| Regular file, UTF-8 name | converted | name and payload bytes are written as a tar member |
| Directory entry | converted | kept as a directory record |
| Special files, device or FIFO entries | rejected | only regular files and directories are handled |
| ZIP64, split or encrypted ZIP | rejected | the reader does not support those variants |
| Absolute, traversal or duplicate paths | rejected | unsafe or ambiguous names are refused |
| Names that are neither ASCII nor valid UTF-8 names | rejected | the name cannot be encoded reliably |
| ZIP symlink or Unix special-file entry | rejected | only regular files and directory records are supported |
Long names in USTAR
USTAR provides a 100-byte basename and a 155-byte prefix. The writer searches for a slash at which the UTF-8 path fits both fields. If no split works, conversion rejects the name rather than shortening it. Rename the file or reduce nesting before trying again; the error identifies the byte-limit problem, not necessarily the offending member.
The practical fix is to rename the offending entries or shorten the folder nesting before repacking, then run the conversion again.
Questions about the ZIP to TAR repack
Does the tar keep file dates and permissions?
Why was my archive rejected when nothing looked wrong?
Is the tar compressed?
Does the listing extract files into folders?
Running the repack in the studio
- Drop the .zip file into the archive studio; one file at a time, up to 12 MiB.
- Pick TAR as the target and choose entry order — archive order or sorted by name.
- Watch the entry count as it reads; the container holds at most 200 entries and each member at most 8 MiB.
- Stop the operation if you spot the wrong bundle; cancellation is real and aborts the read.
- Download the .tar and feed it to the tar-only tool downstream.
- Compare the file list with your source tree, since metadata such as timestamps is not carried over.
Where the size limits bite
Decompression is bounded while it streams, not after: expansion is capped at a 60x ratio and 32 MiB of total expanded content, so a small archive that inflates into a huge tree is stopped instead of filling memory.
- A bundle over 12 MiB of compressed input is refused before reading.
- A member over 8 MiB is refused even if the whole archive is small.
- A bomb that expands past the ratio or total cap stops mid-read with an error.
- Because tar stores members uncompressed, the output is usually larger than the ZIP you started with.
A tarball is the format your pipeline already understands; the ZIP was only the format the export tool chose.
Typical reason for this route