Initializing... drag & drop files here
Supports: ZIP
ZIP (created by Phil Katz at PKWARE in 1989) is the default archive format on Windows and the most common cross-platform container, but it's a poor fit for Unix-style workflows. TAR — short for "tape archive," introduced to Unix in January 1979 and standardized as ustar in IEEE Std 1003.1-1988 — is what almost every Linux, BSD, and macOS command-line tool expects when you're packaging source code, server backups, or container layers. Converting ZIP to TAR gives you a clean tarball you can pipe straight into tar, gzip, xz, pax, or a Dockerfile ADD directive without re-bundling on the destination machine.
make install targets expect a .tar or .tar.gz payload. Shipping a ZIP forces an extra unzip && tar -cf round trip on the server.gzip for fast/universal, bzip2 for older Linux distros, xz or zstd for the smallest size. ZIP locks you into DEFLATE.tar -cf - … | ssh host 'tar -xf -') or into docker import. ZIP's central directory is at the end of the file, which breaks that pattern.pip/npm packages — sdist tarballs, autotools releases, and many language package formats are TAR-based by convention. Reviewers and mirrors expect .tar.gz, not .zip..tgz), and most CI artifact stores standardize on tarballs. A ZIP usually has to be repackaged before it can be cached or shipped.| Property | ZIP | TAR (ustar) |
|---|---|---|
| Year introduced | 1989 (PKWARE) | 1979 (Unix v7) |
| Standard | PKWARE APPNOTE | IEEE Std 1003.1-1988 (POSIX) |
| Compression | Per-file DEFLATE (Deflate64, BZIP2, LZMA, Zstd optional) | None — bundle only; pair with gzip/bzip2/xz/zstd |
| Header / directory | Central directory at end of file | 512-byte header before each member, sequential |
| Random access | Yes — extract one file without reading the rest | No — sequential read required |
| Streaming over a pipe | Limited (needs seek for catalog) | Native — tar was designed for streaming |
| Unix permissions / ownership | Optional (Info-ZIP extension) | Native and required |
| Symbolic & hard links | Possible via Info-ZIP extras | Native first-class members |
| Long filenames | UTF-8 since APPNOTE 6.3.0 (2006) | ustar limits path to 100+155 bytes; pax/GNU extend to unlimited |
| Max archive size | 4 GiB (legacy) / 16 EiB with ZIP64 | No format-level cap (limited by underlying filesystem) |
| Typical extension | .zip |
.tar, .tar.gz/.tgz, .tar.bz2, .tar.xz, .tar.zst |
| Native CLI on Linux | unzip/zip (often a separate package) |
tar (in coreutils on every Unix) |
| Variant | Year | What it adds | When you'd care |
|---|---|---|---|
| V7 (original) | 1979 | Basic 512-byte header, 100-char path | Legacy AIX / very old systems |
| ustar (POSIX.1-1988) | 1988 | UID/GID names, longer paths via prefix, file-type flag | The default for tar -cf on most modern Unix; what xConvert outputs |
| GNU tar | early 1990s | Long names, sparse files, incremental backups | gnu flag set on tar; widely supported but technically non-POSIX |
| pax (POSIX.1-2001) | 2001 | Unlimited filename length, extended attributes via UTF-8 records | Modern macOS/BSD tar (bsdtar) and pax(1) |
Almost always, yes. ZIP applies DEFLATE compression per file, while a plain TAR bundles raw, uncompressed data with a 512-byte header per member. Expect the output TAR to be roughly the sum of the uncompressed file sizes plus a few KB of headers. If size matters, pick a compressed tarball: ZIP to TAR.GZ usually matches or beats the original ZIP, and ZIP to TAR.XZ typically wins by 10–30% on text-heavy archives.
It preserves whatever the source ZIP recorded. ZIPs created by Info-ZIP, zip on Linux/macOS, or 7-Zip with the "Store Unix permissions" option include the chmod bits and UID/GID, and those carry through. ZIPs produced by Windows Explorer or older tools usually have no Unix metadata, so the output TAR falls back to default permissions (typically 644 for files and 755 for directories) under the user running tar -xf.
Yes. Upload all the ZIPs and leave the Combine? option on Single Archive. The contents of every ZIP are extracted and re-packed into one TAR, with the original directory structure preserved. If two ZIPs contain a file at the same path, the later upload wins.
Three common reasons. (1) You're going to compress it yourself with a specific tool — xz -9, zstd --long=27, or a parallel compressor like pigz or pbzip2 — and don't want the converter's choice baked in. (2) The destination already does compression at the storage layer (ZFS, btrfs with compress=zstd, an object store with transparent gzip). (3) You're piping it directly into another process, like docker load, tar -xf -, or a build step that re-packs anyway.
tar on macOS, BSD, and old Linux?Yes. ustar (POSIX.1-1988) is the lowest-common-denominator format that every modern tar reads — GNU tar, BSD tar / bsdtar (the default on macOS and FreeBSD), and the pax utility. The output we produce sticks to ustar headers without GNU or pax extensions, so it round-trips cleanly on AIX, Solaris, and BusyBox tar as well.
ustar caps individual filenames at a 100-byte name field plus a 155-byte prefix (255 total) and individual file size at 8 GiB encoded in the octal size field. Files or paths beyond that need the GNU or pax extensions. Most archives convert without issue, but if your ZIP contains a single file over 8 GiB or a deeply nested path past 255 bytes, the conversion will fall back to GNU long-link records.
No. A ZIP that's encrypted with the legacy ZipCrypto or AES algorithms can't be read without the password, and we don't accept the password through the UI. Decrypt the ZIP locally first with 7-Zip, the macOS Archive Utility, or unzip -P, then upload the resulting plain ZIP for conversion.
Use TAR to ZIP, which decompresses the tarball (if it's .tar.gz/.tar.bz2/.tar.xz) and re-bundles the contents into a DEFLATE-compressed ZIP. You can also explore other archive targets like ZIP to 7Z for tighter compression with Windows-friendly tooling.
Files are uploaded over HTTPS, processed on our server, and then deleted automatically after the session ends — typically within a few hours. We don't index, share, or open the contents. For sensitive archives we still recommend doing the conversion locally with unzip and tar (both free, both shipped with every Linux distribution and macOS install), but the online flow is fine for source code, public release artifacts, and the kinds of files you'd already email or upload to a CI runner.