Convert TZ to TAR.GZ Online (Swapping 1984 Compress for DEFLATE)

What a .TZ Extension Actually Represents

.tz is a shortened extension for a tar archive compressed with the Unix compress command — the identical format more commonly seen written out as .tar.Z, with a third variant, .taz, appearing on the same kind of files as well. Compress itself was first implemented by Spencer Thomas at the University of Utah in 1984, with Joseph Orost and other contributors finishing version 4.0 in 1985 and releasing it as free software distributed over Usenet. Because the compress utility can only shrink one file, not a whole directory tree, packaging multiple files together has always meant running tar first to bundle them, then compress second to shrink the result — the two-step pattern still used today, just with gzip or xz standing in for compress in the second step on modern systems.

Encountering a .tz file today generally means working with something genuinely old: legacy Unix backups, decades-old FTP archive mirrors, or software source trees compressed before gzip existed at all. Rebuilding that file as a .tar.gz means unwinding the original LZW-compressed data completely, then recompressing the same underlying tar contents using gzip's DEFLATE algorithm — a full decompress-then-recompress cycle, not a simple extension rename, since the two compressed byte streams are structurally unrelated.

Why Gzip's DEFLATE Actually Replaced Compress's LZW Coding

Compress's LZW algorithm builds a dictionary of repeated byte sequences while scanning through a file, substituting each recognized sequence with a shorter numeric code that points back into that growing dictionary, starting at 9-bit codes and expanding up to a configurable maximum, usually 16 bits. Gzip's DEFLATE algorithm, defined in RFC 1951, works differently: it combines LZ77's sliding-window match-and-replace approach, which looks for repeated sequences within a fixed window of recently seen bytes, with Huffman coding, which assigns shorter bit patterns to more frequently occurring symbols in what remains after the LZ77 stage.

The actual reason gzip displaced compress wasn't primarily a technical compression-ratio argument, though DEFLATE generally does compress somewhat better on typical data. It was a patent dispute: Sperry Research Center had filed for a patent on LZW in 1983, granted as U.S. patent 4,558,302 in 1985, and Sperry's successor Unisys later began enforcing that patent commercially, most visibly against the GIF image format in a December 1994 royalty announcement that triggered industry-wide backlash. Gzip, built entirely on the patent-free DEFLATE algorithm, became the Unix default specifically to avoid that licensing exposure, and it had already taken over well before the LZW patent finally expired in 2003.

One practical consequence of that history still shows up in file headers today: a compress-format .Z file always begins with a fixed magic number followed by a byte recording the maximum code width used, a built-in sanity check a decompressor reads before proceeding. Gzip files carry their own distinct magic number and header structure entirely unrelated to compress's, which is one more reason the two formats have to be handled as genuinely separate encodings rather than close cousins.

What Changes and What Doesn't When Rebuilding TZ as TAR.GZ

• Gain — a smaller file on most typical data: DEFLATE's LZ77-plus-Huffman design generally compresses text, source code, and similar repetitive content tighter than LZW's older dictionary coding.
• Gain — near-universal modern support: essentially every current operating system, archive tool, and programming language library reads and writes gzip by default, unlike compress-format output.
• Gain — freedom from any patent history: DEFLATE was designed patent-free from release, sidestepping the entire Sperry/Unisys LZW dispute that shaped compress's decline.
• Lose — the original compress-era encoding: once rebuilt, the archive no longer reflects the specific 1984-85 LZW format, only the same file contents recompressed differently.
• Unchanged — every file's actual bytes: both compress and gzip are lossless, so anything extracted from either archive comes out identical to the original source files.
• Lose — nothing meaningful in decompression speed for most uses: gzip decompresses quickly, generally comparable to or faster than compress's own decompression, so this isn't a real trade-off in practice.

Documented Software Support for Both Formats Today

Reading an existing .tz file requires either an old Unix system or a modern tool that deliberately kept compress compatibility: gzip's own uncompress and zcat commands still handle it on Linux, the standalone ncompress package provides the same support, and 7-Zip on Windows along with The Unarchiver on macOS both extract it. Very little current software creates new .Z-compressed files by default, which is the practical reason a .tz archive usually gets converted rather than kept as-is.

Gzip sits on the opposite end of that spectrum entirely. GNU tar supports it directly through the -z or --gzip flag, it's installed by default on virtually every Linux and macOS system, and 7-Zip, WinRAR, and PeaZip all read and write .tar.gz archives on Windows without any extra setup. This isn't a marginal improvement — it's the difference between a format nearly every current tool understands and one that increasingly requires deliberately choosing software that still bothers to support it.

Specific Complaints That Show Up Around Old Compress Files

A recurring report in legacy-system and archive-recovery forums involves a decades-old .tz or .tar.Z file that a particular decompression tool fails to open, which usually traces back to that specific tool not correctly reading the code-width byte in the compress header rather than any actual file damage — compress recorded the maximum bit width used during that particular compression run precisely so a decompressor could rebuild the dictionary correctly, and a tool assuming one fixed width instead of checking the header can misfire on older files that used a different setting.

A second, well-documented pattern involves migration and build-automation scripts written in an earlier Unix era that invoke the compress binary directly by name, which then fail outright when run on a modern minimal Linux distribution or container image that never installs a compress-compatible tool, since it isn't treated as core system software the way gzip is. Reported fixes generally involve rebuilding the affected archives as .tar.gz ahead of the migration itself, rather than trying to keep an aging, rarely maintained compress package installed indefinitely just to satisfy old scripts.

A third complaint surfaces in Windows file-manager threads: some archive utilities recognize the double extension .tar.gz immediately but don't recognize the single .tz extension at all, prompting with a generic "unknown file type" message instead of offering to extract it, even though the underlying compress format is perfectly readable by other tools. Renaming the file to the more widely recognized .tar.Z spelling sometimes resolves this recognition failure on its own, before any actual format conversion takes place.

A fourth issue reported specifically around very old archives involves the code-size cap compress used at the time of creation. Systems from the mid-1980s sometimes capped the maximum LZW code width lower than later systems defaulted to, and a handful of very old .tz files were built under that lower cap. A decompressor that assumes every compress file uses the same maximum width, rather than reading the flag byte the format actually stores for this exact purpose, can misinterpret those specific older files — which is why tools with long-standing, well-tested compress support tend to succeed where newer, narrower implementations occasionally fail.

Compress-Based Compression Set Beside Gzip's DEFLATE

Questions About Replacing Compress Compression With Gzip

Is a .tz file the same thing as .tar.Z?
Yes. Both point to the identical format: a tar archive compressed with the Unix compress utility's LZW algorithm. A third extension, .taz, is used for the same thing as well.

Why did gzip replace compress as the standard Unix compressor?
Mainly because of a patent dispute. Unisys began enforcing its LZW patent commercially in the mid-1990s, and the Unix community shifted to gzip's patent-free DEFLATE algorithm to avoid licensing exposure, years before the LZW patent actually expired in 2003.

Will converting a .tz file to .tar.gz shrink it further?
Usually, yes, though not dramatically. DEFLATE tends to compress typical files somewhat better than the older LZW-based compress algorithm, but the difference is generally more modest than switching to bzip2 or xz.

Does this conversion change the files inside the archive?
No. Compress and gzip are both lossless compression schemes, so every file extracted after conversion is byte-for-byte identical to the original.

Why won't a file manager recognize my .tz file?
Some tools only look for known double extensions like .tar.gz and don't recognize the shortened single .tz extension, even though they can read the underlying format. Renaming it to .tar.Z, or converting it, generally resolves this.