Convert TZ to TAR Online (Reversing Compress's LZW Coding, Nothing Else)

This Conversion Reverses One Algorithm and Touches Nothing Else

A TZ file is a tar archive that has had the Unix compress utility's LZW compression applied over it as a separate second step, and converting it to plain TAR reverses only that step. Tar's own structure — 512-byte header records followed by each file's raw data, unchanged since Seventh Edition Unix in 1979 — is already complete before compress ever runs. Going from TZ to plain TAR means running compress's decompression logic to strip that outer layer away, exposing the exact tar bytes that existed the moment tar itself finished writing them.

Nothing about the resulting TAR file is rebuilt or reorganized — it is the identical tar stream tar originally produced, recovered unchanged. Every file's name, size, permission bits, and ownership information recorded in tar's own headers passes through untouched, since none of it was ever part of the LZW layer being removed; compress only ever compressed the bytes tar had already arranged, and never had any awareness of what those bytes actually meant.

What Reversing LZW Coding Actually Involves

Compress's LZW algorithm builds an adaptive dictionary of byte sequences as it compresses, starting at 9-bit codes and widening up to a maximum set by the -b option — 9 to 16 bits, per the POSIX specification for the utility. Decompression, traditionally handled by the separate uncompress command or gzip's own zcat in compress-compatible mode, rebuilds that same dictionary in reverse as it reads the compressed codes back, reconstructing each original byte sequence from the codes that replaced it.

Every compress-produced stream starts with a fixed two-byte magic number, 0x1F 0x9D, followed by a flag byte recording the maximum code width used during that specific compression run — a decompressor reads that flag first to know exactly how wide the dictionary codes it's about to decode actually are, since compress supports several different maximum widths rather than one fixed value the way some other algorithms do.

This reversal is lossless by definition, the same as any dictionary-coding scheme: LZW never approximates or discards data, it only replaces repeated sequences with shorter codes and then restores them exactly on the way back out. The tar bytes recovered from decompression are identical, bit for bit, to the tar bytes compress originally received, with the same guarantee that applies to gzip's DEFLATE or any other lossless compressor used inside a tar-based archive.

One quirk specific to classic compress is worth knowing about during decompression: the algorithm periodically monitors its own compression ratio while encoding, and when that ratio drops enough, it clears its dictionary and rebuilds it from scratch for the remainder of the file. A correct decompressor has to recognize and replay that same reset at exactly the same point in the stream, or the rest of the decoded output comes out corrupted from that point forward. This is one reason a genuinely faithful compress-compatible decompressor, such as ncompress or gzip's own compatibility mode, matters more here than it does for some other legacy formats — a decompressor that doesn't correctly track LZW's mid-stream dictionary resets can produce a broken result well before reaching the actual end of the file.

What Removing the Compress Layer Gains and What It Costs

• Lose — the size reduction compress provided: a plain TAR file is always larger than the TZ it was decompressed from, though the gap is usually smaller than gzip would have produced, since LZW compresses less tightly to begin with.
• Gain — direct compatibility with tools expecting raw, uncompressed tar data: some scripts and older or specialized software read tar streams directly and have no built-in support for reversing LZW coding themselves.
• Unchanged — every file's name, size, permission, and ownership metadata: that information lives entirely in tar's own headers, untouched by whichever compressor, or none at all, sits on top of it.
• Gain — the ability to append new files directly to the archive: appending onto a plain tar file is far simpler than modifying a compressed stream, which generally has to be fully decompressed and recompressed for any change.
• Unchanged — the actual byte content of every archived file: LZW decompression is lossless, so nothing is altered, approximated, or discarded during this conversion.
• Gain — no dependency on a genuinely obscure decompression tool going forward: once decompressed to plain tar, the file no longer needs ncompress or another compress-compatible reader just to be opened.

Which Tools Actually Reverse This Specific Compression Step

On Linux, the ncompress package provides the uncompress and zcat commands most current distributions no longer ship by default, giving a direct command-line path to strip the LZW layer off a TZ archive. GNU tar's own manual, as of GNU tar 1.35, still documents a -Z / --compress option covering this same decompression, though the manual explicitly recommends against relying on compress generally, describing it as "by far less effective" than the alternatives tar also supports.

7-Zip's own documented list of supported formats places Z (Unix compress) among the formats it can extract but never create, which is exactly the direction this conversion needs — 7-Zip can decompress an existing TZ archive down to plain tar without issue, even though it has no way to compress a file back into that same format afterward.

Apple's Archive Utility on macOS lists the plain lowercase .z extension among the formats it opens, but doesn't specifically name .tz or .taz in that same documented feature list, so a genuinely reliable path on macOS for this exact conversion often means using Terminal's own uncompress-compatible tools rather than assuming Archive Utility handles every variant of the extension identically. Windows has no built-in graphical support for either side of this conversion, though its command-line tar.exe, based on libarchive and shipped since Windows 10 version 1803, is documented as reading a range of compressed tar formats from a terminal.

The Actual Reasons Someone Strips Compress Off a TZ File

A documented, practical reason for this conversion involves feeding an archive into a tool or pipeline built to expect raw, uncompressed tar data, where the software has no built-in handling for LZW decoding at all — stripping compress's layer beforehand avoids a flat failure from a program that only understands tar's own header structure and nothing wrapped around it.

A second real pattern involves preparing an old archive for recompression with a modern algorithm: since compress's LZW coding generally compresses less tightly than gzip, bzip2, or xz, decompressing to plain TAR first is the necessary intermediate step before applying any of those newer compressors, because none of them read a compress-encoded stream directly as their own input format. A third scenario involves archival and data-recovery work specifically, where investigators prefer working against an uncompressed tar stream because low-level tools scanning for known byte patterns can read raw tar data directly, a task made far harder against LZW-compressed bytes where those same patterns are scrambled by the coding.

A fourth pattern shows up in workflows migrating old Unix backups onto current systems where the destination software has never supported compress specifically, having been written well after gzip displaced it as the standard choice — decompressing to plain TAR first sidesteps that gap entirely, since a plain tar reader has no compression format to worry about at all.

Compressed TZ Set Against the Plain TAR It Decompresses Into

Questions About Removing Compress's Layer From a TZ File

Does converting TZ to TAR change anything about the files inside?
No. Reversing compress's LZW coding is a lossless, purely mechanical process — every file's content, name, permissions, and ownership metadata comes out identical to what tar wrote before compress ever ran.

Why would I want a bigger, uncompressed TAR file instead of keeping the TZ?
Mainly for compatibility with software that expects raw tar data and has no built-in LZW decoding, or as a required first step before recompressing with gzip, bzip2, or xz, since none of those tools read a compress-encoded stream as their own input.

Can I just rename my TZ file to .tar and get the same result?
No. Renaming doesn't decompress anything — the file would still hold LZW-compressed data under a misleading extension, and a plain tar reader expecting uncompressed data would fail to read it.

Is there any risk of data loss when reversing compress's LZW coding?
No. LZW, like the algorithms used in gzip or bzip2, is lossless by design, so decompression recovers the exact original tar bytes with nothing discarded.

Will the resulting TAR file open the same way the TZ did?
Yes, in terms of the files inside. Any tool that reads plain tar archives will list and extract the same files, in the same order, with the same names and permissions, since decompression only removes compress's wrapper and leaves the underlying tar structure exactly as it was.