Convert TAR.Z to ZIP Online (Unix Compress Tarball to PKWARE Archive)

How a TAR.Z Archive Combines Two Separate Unix-Era Steps

A .tar.Z file is not one format but two, stacked in a specific order. First, the Unix tar command bundles a set of files and directories into a single .tar stream, preserving each entry's Unix permissions, ownership, and symbolic links in a fixed-layout header ahead of every file's raw data. Second, that whole .tar stream gets run through the compress utility, the LZW-based Unix compression program first written by Spencer Thomas in 1984 and finalized as version 4.0 in 1985, which adds its own header (a fixed magic number plus a byte recording the maximum code size used) and treats the tar stream as one opaque blob of bytes to shrink.

This two-step pattern is exactly why the extension has three parts instead of one: ".tar" records what the container is, and ".Z" records what compressed it, the same convention gzip later reused for ".tar.gz" and bzip2 for ".tar.bz2." Before gzip existed, ".tar.Z" was the standard way Unix systems packaged and shrank multiple files together, and it remained the default on many systems well into the early 1990s.

Unpacking the Compress Layer Before Rebuilding as a ZIP Container

Converting a TAR.Z file to a ZIP means undoing both of those steps and replacing them with ZIP's own single-container design. First the compress layer has to be reversed, decoding the LZW-compressed bytes back into the original plain .tar stream. Then that .tar stream has to be parsed entry by entry — reading each file's Unix header, extracting its raw data — because a ZIP archive doesn't wrap a tar stream the way TAR.Z does; a ZIP holds each file as its own separately compressed entry with its own local header, listed in a central directory at the end of the archive.

That structural difference has a real consequence for anything the original tar header stored beyond filenames and sizes. Unix tar headers record file permission bits (like whether a file is executable), numeric owner and group IDs, and whether an entry is a symbolic link rather than a real file. The ZIP specification has no core field for any of that; Unix permissions and symlink targets can only survive in ZIP through PKWARE's optional "Info-ZIP Unix extra field," which not every ZIP-writing tool bothers to include and even fewer ZIP-reading tools on Windows actually restore on extraction.

What Survives the Move From TAR.Z to ZIP and What Doesn't

• Gain — near-universal desktop support: a ZIP opens with a double-click in Windows Explorer and macOS Finder, while a TAR.Z needs a tool that specifically still understands 1985-era compress output.
• Gain — usually a smaller file, sometimes not: ZIP's default DEFLATE method generally beats compress's LZW on the same data, though the gap depends heavily on what's inside — text and source code shrink noticeably more under DEFLATE than under compress's fixed 16-bit code ceiling.
• Gain — per-file access without decompressing everything: a ZIP's central directory lets a tool jump straight to one file's data; a TAR.Z has to be decompressed as one continuous LZW stream from the start before any single file inside it can be read.
• Lose — Unix permission bits by default: executable flags and ownership recorded in the tar header aren't part of ZIP's core spec and often don't survive unless both the writing and reading tool support the Info-ZIP Unix extra field.
• Lose — symbolic links as links: without that same extra field being written and honored, a symlink inside the original tar often extracts from the ZIP as a plain copy of the target file instead of a link pointing to it.
• Lose — the specific LZW encoding history: once rebuilt, there's no trace left of the original compress code-size setting or magic number; the new ZIP entry is compressed fresh with DEFLATE, unrelated to the old LZW bytes.

Software That Actually Opens a Decades-Old TAR.Z Today

No mainstream Windows or macOS tool decompresses TAR.Z by simply double-clicking it the way ZIP works. On Linux and macOS, the standard route is gzip's own uncompress or zcat command to strip the compress layer, piped into tar to unpack what's left — both ship by default on virtually every current Linux distribution and macOS's Terminal specifically because so much archived Unix documentation and source code from the 1980s and 1990s still exists in this exact format. On Windows, 7-Zip is the practical option: it recognizes the compress LZW format directly and can unpack a TAR.Z in one pass without needing a separate Unix-style pipeline.

Rebuilding the result as a ZIP is comparatively unremarkable by comparison — 7-Zip, WinRAR, PeaZip, and File Explorer's own built-in "Compress to zip file" can all create a standard DEFLATE-compressed ZIP from an already-extracted folder, since the difficult part of this conversion is entirely on the TAR.Z decoding side, not the ZIP-building side.

Command-line users on any platform can also handle both steps at once with GNU tar, which auto-detects a compress-compressed stream and extracts it directly with a single tar -xZf archive.tar.Z command, skipping the separate uncompress-then-untar pipeline entirely before the extracted contents get rezipped.

Where TAR.Z-to-ZIP Conversions Actually Go Wrong

A frequent point of confusion in Unix support threads is someone running gunzip directly on a .tar.Z file and getting an error like "not in gzip format," because gzip's own decompressor and the older compress format are related in purpose but use different algorithms — DEFLATE versus LZW — and different magic numbers in the file header. The fix reported to resolve this specific error is using uncompress or zcat instead of plain gunzip, or letting a tool like 7-Zip auto-detect the format rather than assuming any file with a compression-sounding extension is gzip's.

A second real, documented issue involves the compress header's own maximum-code-size byte: some very old .tar.Z files were created with a lower maximum bit width than modern decompressors assume by default, and decompressors that don't correctly read that byte from the file header instead of assuming one fixed setting can fail on those older files. This is a narrow edge case specific to compress's file format design, not something that shows up with ZIP or gzip.

A third recurring complaint, this one specific to the rebuild step, is a Linux user extracting Unix permissions or symlinks correctly from the original tar, rebuilding as ZIP, and then finding those permissions gone or a symlink replaced by a duplicate file after unzipping on a different machine — a direct consequence of the Info-ZIP Unix extra field not being written, not read, or both, and not a bug in either tool individually.

TAR.Z Compression Held Up Against a Rebuilt ZIP Archive

Common Questions About Converting an Old TAR.Z Archive to ZIP

Why does my TAR.Z file need two steps to open instead of one?
Because it actually is two formats stacked together — a tar container bundling multiple files, then a separate compress pass shrinking that whole bundle. ZIP handles both jobs in one structure, which is part of why converting between them isn't a simple rename.

Will file permissions from my original tar survive as a ZIP?
Not reliably. ZIP's core specification has no dedicated field for Unix permission bits or symlinks; they only carry over if both the tool creating the ZIP and the tool extracting it support the optional Info-ZIP Unix extra field.

Why did gunzip fail on my .tar.Z file?
Because gzip's gunzip and the older Unix compress use different algorithms and different file headers — DEFLATE versus LZW. Use uncompress or zcat instead, or a tool like 7-Zip that auto-detects the actual compression format.

Is a TAR.Z file the same thing as a .Z file?
Not quite. A plain .Z file is compress applied directly to one file. A TAR.Z is compress applied to a tar archive that itself may contain many files and folders — the .Z compression step is identical in both cases, but what's inside differs.

Does rebuilding as ZIP make the file smaller?
Usually, since ZIP's default DEFLATE method generally compresses better than compress's older LZW scheme, especially on text-heavy data, though the exact difference depends on what the archive actually contains.