Convert TZ to TAR.BZ2 Online (From 1980s Unix Compress to Burrows-Wheeler Compression)

Where a .TZ File Comes From and What's Actually Inside It

A .tz file is a tar archive that was run through the Unix compress command, the same result as a .tar.Z file — .tz is simply a shortened form of that longer extension, alongside a third variant, .taz, that shows up on the same kind of archives. The compress utility itself dates to 1984, first implemented by Spencer Thomas at the University of Utah, with Joseph Orost and collaborators finalizing version 4.0 in 1985 and releasing it as free software. Because compress can only ever squeeze one file at a time, packaging a whole directory tree means running tar first to bundle everything into a single file, then running compress on that result — the same two-step pattern gzip and xz still use with tar today, just with an older algorithm doing the second step.

Opening a .tz file today almost always means dealing with something old: decades-old FTP mirrors, archived Unix source trees, legacy backup sets, or man-page distributions compressed before gzip existed and never repackaged since. Rebuilding one as a .tar.bz2 file means fully decompressing the original LZW-compressed data, then recompressing the same tar contents with bzip2's completely different algorithm — not a simple rename, since the two compression schemes produce structurally unrelated byte streams.

The tar layer underneath either compression scheme is identical either way, which is worth being clear about: tar itself is a sequential container format, originally designed for writing data to magnetic tape (hence "tape archive"), that stores each file as a 512-byte header block describing its name, permissions, and size, immediately followed by the file's own data padded out to the next 512-byte boundary. Neither compress nor bzip2 changes anything about that internal tar structure — they only change how the finished tar stream gets shrunk for storage, which is exactly why a .tz file has to be fully unwound back to its plain, uncompressed tar form as an intermediate step before bzip2 can compress it again from scratch.

LZW Dictionary Codes Versus the Burrows-Wheeler Block Sort

Compress's LZW encoding builds a dictionary of repeated byte sequences as it scans the file and replaces those sequences with progressively wider numeric codes, starting at 9 bits and growing up to a configurable maximum, typically 16 bits, as the dictionary fills up. Bzip2, written by Julian Seward and first released in 1996, works nothing like this. It rearranges data in fixed-size blocks — up to 900 KB per block at the default and highest setting — using the Burrows-Wheeler Transform, a reordering step that groups similar byte contexts together without changing what bytes are present, followed by a move-to-front transform and Huffman coding on the result.

That block-based design has a real, practical side effect LZW compression doesn't share: each 900 KB block in a bzip2 stream is compressed independently, which is exactly what lets tools like pbzip2 compress or decompress different blocks on separate CPU cores in parallel, and it's also why a bzip2 file with one damaged block can sometimes still yield up its other, undamaged blocks using the bzip2recover utility — a targeted recovery option that a single continuous LZW stream doesn't offer in the same way, since damage partway through a compress stream corrupts everything from that point onward.

On most typical file types, bzip2's block-sorting approach compresses noticeably tighter than compress's older LZW scheme, though it generally runs slower doing it, since the Burrows-Wheeler Transform and the multiple encoding passes bzip2 performs per block take more CPU time than LZW's simpler dictionary lookups.

What Rebuilding This Archive as TAR.BZ2 Actually Changes

• Gain — a smaller archive on most typical data: bzip2's block-sorting compression generally beats LZW's dictionary coding by a real, measurable margin on text, source code, and similar repetitive data.
• Gain — block-level damage recovery: bzip2's independent 900 KB blocks can sometimes be partially recovered with bzip2recover if part of the file is damaged, unlike a single unbroken compress stream.
• Gain — active tool support: bzip2 remains a maintained, widely available Unix compressor, while compress-writing tools have become genuinely scarce outside legacy systems.
• Lose — decompression speed: bzip2 typically decompresses more slowly than the LZW-based compress format, since its multi-stage decoding pipeline does more work per byte.
• Unchanged — the actual file contents: both are lossless compression schemes, so every file inside the tar archive comes out byte-for-byte identical after extraction either way.
• Lose — the historical curiosity value: a .tz file is itself a small piece of Unix history; converting it away from LZW compression means the archive no longer reflects the original compress-era encoding, only its contents.

Which Systems Still Read Compress Output Versus Bzip2

Reading a .tz file today generally requires either a genuinely old Unix system or a modern tool that specifically retained compress compatibility: gzip's own uncompress and zcat commands still handle it on Linux, along with the separate ncompress package, while 7-Zip on Windows and The Unarchiver on macOS both extract it as well. Very little modern software writes new .Z-compressed output by default anymore, which is the core reason a .tz file usually needs converting rather than simply being left as-is.

Bzip2, by contrast, sits solidly inside current default tooling. GNU tar supports it directly through its -j or --bzip2 flag, essentially every Linux distribution ships the bzip2 command by default, and 7-Zip, WinRAR, and PeaZip all read and write .tar.bz2 archives on Windows and macOS without any extra configuration. This is a genuine, current compatibility upgrade over the original .tz file, not just a cosmetic difference in extension.

Real Problems Reported Around Old Compress Archives

A recurring complaint in old software-archaeology and legacy-migration threads involves a .tz or .tar.Z file that a modern extraction tool refuses to open at all, tracing back to that file predating gzip's own compress-compatible mode or using a code-size setting some newer decompressors don't check for correctly — compress's header stores the maximum code width used during that specific compression run, and a decompressor that assumes one fixed setting instead of reading that byte can fail on older files. The documented fix is simply using a tool, such as 7-Zip or the ncompress package, that reads the header correctly rather than assuming a single hardcoded configuration.

A second real pattern shows up in build-system and package-migration discussions: scripts written decades ago that call the compress binary by name, expecting .Z output, break outright when moved to a modern minimal Linux container image that never installs a compress-compatible tool by default, since it's no longer considered essential the way gzip or tar are. Rebuilding the affected archives as .tar.bz2 or .tar.gz ahead of the migration, rather than trying to keep compress installed indefinitely, is the fix reported to actually resolve this for good.

A third, more subtle report involves file managers and archive utilities on Windows that recognize .tar.gz or .tar.bz2 by their double extension but treat .tz as an unfamiliar single extension, sometimes prompting to open it with a generic decompression tool that then fails silently rather than clearly reporting that it doesn't know the format. Renaming the file to end in .tar.Z, the more widely recognized spelling of the exact same format, occasionally resolves this misidentification on its own even before any actual conversion happens, since some tools key off the extension text rather than inspecting the file's actual header bytes.

Compress-Based TZ Set Beside Bzip2's Block-Sorting Format

Questions About Moving From Compress to Bzip2 Compression

Why won't my .tz file open in a newer archive tool?
It's usually a compress header the tool doesn't parse correctly, not file corruption. Tools like 7-Zip, ncompress, or gzip's own uncompress command generally handle it correctly by reading the code-size byte in the file's header.

Will converting a .tz file to .tar.bz2 shrink it?
In most cases, yes. Bzip2's Burrows-Wheeler Transform generally compresses typical files, especially text and source code, more tightly than the older LZW-based compress algorithm.

Does the conversion change any of the files inside the archive?
No. Both compress and bzip2 are lossless, so every file extracted from either archive is byte-for-byte identical to the original once decompressed.

Is .tz the same thing as .tar.Z or .taz?
Yes. All three are extensions used for the exact same underlying format: a tar archive compressed with the Unix compress utility's LZW algorithm.

Can a damaged .tar.bz2 file still be partly recovered?
Often, yes. Because bzip2 compresses data in independent blocks up to 900 KB each, a tool like bzip2recover can sometimes extract the undamaged blocks even when part of the file is corrupted.