Convert TZ to ZIP Online (From Unix Compress Tarballs to PKWARE's Container)

The Unix Origins of a .TZ Archive

A .tz file is a tar archive that has been compressed with the Unix compress command — functionally identical to the more commonly seen .tar.Z extension, plus a third variant, .taz, used for the same format. Compress was first written by Spencer Thomas at the University of Utah in 1984, with Joseph Orost and other contributors finalizing version 4.0 in 1985 and releasing it as free software. Since compress only ever shrinks a single file and has no concept of bundling multiple files together, packaging a directory tree has always required tar first, to combine everything into one file, then compress second, to shrink that combined result.

Encountering a .tz file today usually means working with something genuinely old: an archived Unix source tree, a legacy FTP mirror, or a decades-old backup set compressed before gzip or newer formats existed. Moving that data into a .zip file means something structurally bigger than simply recompressing it — it means unpacking the entire tar-plus-compress arrangement and rebuilding the contents inside a completely different container format that was never designed with Unix's tar-then-compress pattern in mind at all.

Two Fundamentally Different Container Designs, Not Just Two Compression Algorithms

The difference between a .tz file and a .zip file runs deeper than which compression algorithm gets used. Tar is a sequential container: each file inside gets a 512-byte header block recording its name and metadata, immediately followed by that file's data, one after another in a single continuous stream with no built-in index of what's inside or where anything sits — a design that traces back to writing data onto magnetic tape, where sequential access was the only option anyway. Compression, when applied, wraps around the entire finished tar stream as one pass.

ZIP, defined in PKWARE's APPNOTE.TXT specification since 1989, works the opposite way: every file gets compressed individually, each with its own local header, and a central directory at the very end of the archive lists every entry's name, size, and exact byte offset within the file. That structural difference is why a ZIP reader can jump straight to any single file inside a large archive without reading anything before it, while a compressed tar stream generally has to be decompressed from the beginning to reach a specific file — a real, practical distinction for anyone extracting just one item from a large archive rather than everything at once.

Because of this, converting a .tz file to .zip isn't simply swapping LZW compression for ZIP's usual DEFLATE method. It requires decompressing the tar stream fully, reading each file's data back out of that sequential layout, and reassembling everything as individually compressed entries with their own headers plus a freshly built central directory — a genuine rebuild from one file-storage philosophy into another, not a like-for-like recompression.

What Moving From TZ to ZIP Gains and What It Loses

• Gain — per-file random access: ZIP's central directory lets a reader extract one specific file without decompressing everything before it, unlike a sequential compressed tar stream.
• Gain — native support on Windows and macOS: both operating systems can open ZIP files without installing anything extra, while .tz requires dedicated Unix-heritage tooling most non-technical users don't have.
• Gain — better typical compression than LZW: ZIP's default DEFLATE method generally compresses text and similar data more tightly than compress's older dictionary-coding scheme.
• Lose — Unix file permission and ownership metadata: tar headers record Unix permission bits, owning user, and owning group for every file; standard ZIP entries don't reliably carry that same metadata across all tools.
• Lose — the original compress-era encoding entirely: the resulting ZIP no longer reflects the archive's LZW history at all, since the format itself is unrelated at every structural level.
• Unchanged — the actual file contents: both formats use lossless compression, so anything extracted from the rebuilt ZIP is identical, byte for byte, to what was inside the original .tz file.

Where Each Format Is Actually Usable Without Extra Tools

Reading a .tz file requires either a genuine Unix or Linux system with compress-compatible tooling — gzip's own uncompress and zcat commands, or the standalone ncompress package — or a dedicated third-party tool like 7-Zip on Windows or The Unarchiver on macOS, since neither operating system opens it natively out of the box. Very little current software writes new .Z-compressed files by default anymore, so a .tz archive is almost always something being read, not created, on a modern system.

ZIP sits at the opposite end of the compatibility spectrum: Windows has included native ZIP support since Windows XP through its integrated Compressed Folders feature, macOS has built-in ZIP support through Finder and Archive Utility, and mobile operating systems generally handle ZIP files without any extra app at all. This is precisely why .tz-to-.zip conversions get requested in the first place — not because ZIP compresses meaningfully better in every case, but because it's the one archive format almost every recipient, regardless of platform or technical background, can already open.

Documented Complaints From Cross-Platform File-Sharing Threads

A common report in cross-platform support forums involves a Linux or Unix user sending a .tar.Z or .tz archive to a colleague on Windows, who then has no idea how to open it and, in some documented cases, mistakes the extension for a typo or an unfamiliar video file format entirely. The practical fix reported in these threads is consistently the same: convert the archive to ZIP before sending it, rather than expecting the recipient to install unfamiliar Unix compression tooling just to read a handful of files.

A second recurring issue involves lost Unix file permissions after a .tz archive gets rebuilt as a ZIP: executable scripts that had their execute bit set inside the original tar archive sometimes lose that bit once repackaged into a ZIP, because not every ZIP-writing tool preserves Unix permission metadata in the same extended attribute fields, and not every ZIP-reading tool on the extraction side interprets those fields even when they are present. This is a documented, real compatibility gap specifically tied to Unix permission bits, not a general file-corruption issue, and it's worth checking permissions manually on any scripts extracted from a converted archive rather than assuming they carried over automatically.

A third pattern shows up around symbolic links: tar archives can store a symlink as its own distinct entry type, recording just the link's target path rather than a copy of the actual file, but the base ZIP specification doesn't define an equivalent native symlink entry type the same way, so some ZIP-writing tools either resolve symlinks into full copies of their target file during conversion or drop them entirely, depending on the specific tool involved. Checking how a chosen conversion tool actually treats symlinks is a legitimate concern for any archive that contains them, since the outcome genuinely differs between implementations.

Unix Tarball Storage Compared With PKWARE's Container Format

Common Questions About Bringing Old Compress Archives Into ZIP

Why can't I just open a .tz file on Windows the way I open a ZIP?
Windows has no built-in support for the Unix compress format .tz files use. A tool like 7-Zip is needed to read it, whereas ZIP has been natively supported in Windows since Windows XP.

Will my file permissions survive converting from .tz to .zip?
Not always reliably. Tar stores Unix permission and ownership metadata natively, but standard ZIP entries don't consistently preserve that same metadata across every tool, so it's worth checking permissions on extracted scripts.

What happens to symbolic links during this conversion?
It depends on the specific tool. Tar has a native symlink entry type; the base ZIP format doesn't define an equivalent, so some tools convert a symlink into a full copy of its target file, and others may drop it.

Does converting to ZIP lose any of the actual file data?
No. Both compress and ZIP's default DEFLATE method are lossless compression schemes, so every file extracted afterward is identical to the original, byte for byte.

Is .tz the same as .tar.Z?
Yes, they're the exact same format under two different extension spellings, along with a third variant, .taz, used for the same thing.

Can I extract just one file from a .tz archive without unpacking everything?
Not practically. A compressed tar stream is sequential with no index of its contents, so most tools need to decompress from the beginning to reach a specific file, unlike ZIP's central directory, which points directly to any single entry's location.