Convert Z to TAR Online (Removing 1984 LZW Compression From a Tarball)

The Oldest Compression-Plus-Archive Pairing Still in Circulation

A .tar.Z file follows the exact same two-step pattern later adopted by .tar.gz and .tar.xz, just with the oldest compression algorithm in that lineage: TAR bundles files, folders, and Unix permissions into one archive first, and the Unix compress command, written by Spencer Thomas in 1984 and finalized as version 4.0 in 1985, compresses that bundle second using LZW coding. TAR itself is even older, tracing back to early Unix tape backup tools that predate compress, which means this specific pairing represents some of the earliest still-recognizable archive tooling from the personal-computing and early-Unix era.

Converting .tar.Z to .tar means decompressing the LZW layer and recovering the plain tarball underneath, exactly the way removing gzip from a .tar.gz file recovers the same plain tarball structure. Nothing about the archive's internal file list, folder structure, or Unix permission bits changes during this step — only the LZW compression wrapper comes off.

The naming convention itself, stacking two dots and two extensions, has stayed consistent across every generation of this pairing since compress was new: whatever comes before the last dot describes how the files were bundled, and whatever comes after describes how that bundle was compressed. A .tar.Z file is simply the oldest surviving example of that naming pattern still occasionally seen today, predating .tar.gz, .tar.bz2, and .tar.xz by years or decades depending on which one you compare it against.

LZW's Adaptive Codes Against TAR's Complete Lack of Compression

Compress's LZW implementation encodes the tarball's byte stream using codes that start at 9 bits and adaptively grow up to a maximum, typically 16 bits, as its internal dictionary of previously-seen byte sequences fills up, with that maximum recorded in the compressed file's own header so a decompressor knows exactly how to reverse the process. TAR, underneath all of this, applies no compression at all — it's purely a way of concatenating files together with headers describing each entry's name, owner, permission bits, and size, a structure completely unrelated to whatever compression algorithm, if any, gets applied to it afterward.

This division of labor between TAR handling structure and compress handling size reduction is precisely why decompressing a .tar.Z file back to plain .tar doesn't restructure anything — the file list, permissions, and folder paths inside were never touched by the compression step to begin with, since LZW operates purely on the raw byte stream without any awareness of what that stream represents.

It's worth noting compress's dictionary reset behavior as well: once the dictionary fills to its configured maximum size, compress can either stop learning new sequences and keep using what it has, or reset the dictionary and start building it fresh, depending on how the specific implementation and settings were configured. Either behavior only affects how tightly the file compresses, never the correctness of what gets stored — the tarball's actual content is reconstructed identically either way once the file is decompressed.

What Comes Back and What Disappears When LZW Is Removed

• Lose — whatever size reduction LZW was providing: LZW's dictionary coding generally shrinks a file less than DEFLATE or LZMA2 would, but it still shrinks it meaningfully compared to storing it raw, so removing it makes the file noticeably bigger.
• Gain — a file readable by absolutely anything that understands TAR: plain .tar has been openable on essentially every Unix-family system since the 1980s, with no LZW decoder required at all.
• Unchanged — every filename, folder path, and Unix permission bit: TAR's own archive structure passes through decompression completely intact, since compress never modified it in the first place.
• Gain — compatibility with tools that reject .Z outright: some modern intake systems and upload forms recognize .tar but flatly reject the older, less common .Z extension.
• Lose — the compress magic-number header's built-in sanity check: that header, which lets a decompressor confirm a file is actually valid compress output before proceeding, no longer applies once the file is plain, uncompressed TAR.

Where .tar.Z Archives Still Turn Up on Real Systems

Genuine .tar.Z files today are almost always something inherited rather than newly created — decades-old Unix system backups, archived FTP mirrors from the 1990s, old academic dataset distributions, or legacy source-code snapshots compressed before gzip existed or before a given project had switched to it. Gzip, built on the patent-free DEFLATE algorithm, displaced compress as the default Unix compression tool well before the LZW patent that had encumbered it actually expired in 2003, which means any .tar.Z file still circulating today is generally old enough to predate that wider industry shift rather than being a recent, deliberate choice.

Most current systems can still open these files without much trouble: Linux distributions typically retain compress-compatible decompression through gzip's own zcat or a dedicated uncompress command, while 7-Zip on Windows and The Unarchiver on macOS both handle extraction as well, even though virtually none of these tools default to creating new .Z-compressed output anymore.

This gap between broad decompression support and narrow, mostly command-line-only creation support is itself informative: it shows the format never actually disappeared from the software ecosystem the way a truly abandoned format would, since maintaining decompression support costs software vendors very little and protects against exactly the scenario of someone needing to open a decades-old archive they can no longer regenerate. What disappeared was compress's role as anyone's default choice for new files, not its underlying readability.

The Actual Cause Behind "My Extracted TAR File Is Way Bigger Than I Expected"

A common point of confusion when unwrapping an old .tar.Z archive is surprise at how much larger the resulting plain .tar file is compared to the compressed original, sometimes leading people to assume something went wrong during the conversion. This is expected behavior, not an error: LZW compression, even though it's less aggressive than newer algorithms, was still doing real work shrinking the file, and removing that compression simply restores the tarball to something close to its original, uncompressed size — the same expected size increase that happens removing gzip from a .tar.gz or XZ from a .tar.xz file.

A second, more specific issue documented in old system-administration forums involves .tar.Z archives created on systems that used a lower maximum LZW code width than 16 bits, since compress allowed configuring this maximum, and some modern decompression tools assume the more common 16-bit maximum by default rather than reading the actual flag byte recorded in that particular file's header. Confirming the decompression tool reads this header value correctly, rather than assuming one fixed setting, resolves this narrow but real compatibility gap with certain older archives.

A third pattern shows up when someone tries to open a .tar.Z file using a tool that only understands the more common .tar.gz and .tar.xz extensions and doesn't recognize .Z at all, leading to a generic "unsupported format" error rather than any indication of what's actually wrong. Since the file itself isn't damaged, switching to a tool with explicit compress support, such as 7-Zip, or manually running gzip's uncompress command from a terminal, resolves this specific and easily misdiagnosed error.

LZW-Compressed Tarball Set Beside Its Plain, Uncompressed Form

Questions About Unwrapping an Old Tar.Z Archive

Why is my .tar file so much bigger after decompressing?
Because LZW compression was genuinely shrinking the file, even if less effectively than modern algorithms would. Removing it restores the tarball close to its original, uncompressed size, which is expected and not a sign of corruption.

Does this conversion lose any files inside the archive?
No. TAR's file list, folder structure, and Unix permission bits pass through completely unchanged; compress only ever touches the compressed byte stream, never the archive structure itself.

How old is a typical .tar.Z file likely to be?
Usually from the 1980s or 1990s, since gzip displaced compress as the default Unix compression tool well before the LZW patent expired in 2003, meaning most .tar.Z files in circulation predate that shift.

What tools can still open a .tar.Z file today?
Most Linux distributions via gzip's own zcat or uncompress commands, plus 7-Zip on Windows and The Unarchiver on macOS, even though almost none of these tools create new .Z-compressed files by default anymore.

Should I bother re-compressing my recovered TAR file with gzip or XZ?
Generally yes, if you plan to keep the archive around. Gzip and especially XZ compress noticeably tighter than the older LZW-based compress format did, so recompressing with a modern algorithm typically produces a smaller final file than the original .tar.Z was.