Convert TZ to 7Z Online (Replacing 1980s LZW With LZMA2 on the Same Tar Data)

How a Tar-Plus-Compress File Gets Rebuilt Into 7-Zip's Container

A TZ file is a tar archive — files bundled with 512-byte header records, a structure unchanged since Seventh Edition Unix in 1979 — compressed as a single stream with the Unix compress utility, whose Lempel-Ziv-Welch algorithm was first implemented by Spencer Thomas in 1984 and finalized as version 4.0 in 1985. A 7Z file is a much newer, completely different container, created by Igor Pavlov for the 7-Zip project and first released in 1999, built around the LZMA algorithm and its own internal header describing every file, folder, and compression setting.

Converting TZ to 7Z means reversing compress's LZW encoding to expose the plain tar stream underneath, unpacking that tar structure into individual files, and then rebuilding an entirely new archive around 7Z's container using LZMA2, the variant 7-Zip has defaulted to since version 9.20. Nothing about this is a simple algorithm swap on the same container — TZ and 7Z share no structural design at all, so the files come out the other side of a genuine rebuild rather than a like-for-like recompression.

Why LZMA2's Modern Design Leaves 1980s LZW Far Behind

Compress's LZW coding builds an adaptive dictionary of byte sequences it has already seen, starting at 9-bit codes and widening as needed, up to a maximum set by the -b option that the POSIX specification documents as ranging from 9 to 16 bits. Critically, LZW on its own is the entire compression step — there's no separate entropy-coding pass afterward the way gzip layers Huffman coding on top of its own LZ77 stage. LZMA2, by contrast, combines an LZ77-style dictionary search with range coding as a genuine second stage, squeezing extra redundancy out of the data that LZW's single-pass design was never built to capture in the first place.

The dictionary sizes involved aren't remotely comparable either. LZW's code width tops out at 16 bits, meaning its dictionary can hold at most 65,536 distinct entries before it has to reset, while LZMA2's dictionary can scale up to 64 MB or more depending on the compression level chosen — a difference of several orders of magnitude in how much prior data each algorithm can draw on to spot repetition. That gap, layered on top of LZMA2's added range-coding stage, is why a 7Z rebuilt from a TZ archive routinely comes out substantially smaller, not just marginally so.

7-Zip's compression levels, from "Store" through "Ultra," also let dictionary size and search depth be tuned explicitly for the conversion, a degree of control the original compress utility's simple -b bit-width flag never offered, since compress has no equivalent notion of adjustable search depth at all.

There's also a practical asymmetry worth noting: compress's dictionary isn't just smaller, it behaves differently once full. When LZW's code table fills up to whatever maximum width was chosen, classic compress implementations reset the dictionary and start building it again from scratch partway through the file, discarding everything learned up to that point. LZMA2 has no equivalent forced reset built into its normal operation at a given compression level — its much larger dictionary window simply keeps sliding forward, continuing to reference far-back data rather than throwing its accumulated knowledge away partway through a long file. For an archive holding several similar files bundled together by tar, that difference in whether prior context survives across the whole stream compounds directly with the dictionary-size gap already covered above.

What Trading LZW for LZMA2 Gains and What It Costs

• Gain — a meaningfully smaller file in nearly every case: LZMA2's larger dictionary and range-coding stage outperform LZW's simple, single-pass design by a wide, consistent margin.
• Lose — the ability to reopen the file with genuinely ancient decompression tools: some ancient Unix systems can read a TZ's LZW stream but have no way to decode LZMA2 at all.
• Gain — optional AES-256 encryption for both contents and filenames: compress has no password-protection mechanism of any kind, while 7Z supports it as a built-in option.
• Lose — a format 7-Zip can create by default: 7-Zip's own supported-formats list places Z among formats it only extracts, so a 7Z conversion depends on 7-Zip's genuine strength — reading the source, not writing it.
• Lose — native macOS Archive Utility support: Apple's documented natively-supported list doesn't include .7z, so opening the result on a Mac needs a separate tool like The Unarchiver or Keka.
• Unchanged — every extracted file's actual content: both LZW and LZMA2 are lossless, so what comes out of either archive is byte-for-byte identical.

Documented Compatibility on Each Side of This Conversion

7-Zip's own documented list of supported formats places Z (Unix compress) among the formats it can open and extract but never create — which lines up exactly with what a TZ-to-7Z conversion needs from it, since 7-Zip only has to read the old format here, not write it. On the output side, 7-Zip creates 7Z archives natively as its own primary format, with no such limitation.

Opening the resulting 7Z file has its own platform story: Windows needs 7-Zip itself or another third-party tool, since File Explorer's built-in archive support covers only ZIP. macOS needs The Unarchiver, Keka, or a similarly capable tool, because Apple's Archive Utility feature list doesn't name .7z among the formats it opens directly. Linux distributions generally require installing p7zip or the newer 7-Zip for Linux package through the system's package manager, since 7Z support isn't part of any mainstream distribution's base install the way tar already is.

On the source side, genuinely old TZ archives sometimes predate even ncompress, in which case a Linux system needs that package installed specifically to provide compress-compatible decompression before any conversion tool can read the file at all — a real, documented dependency gap on minimal or freshly installed systems that don't ship it by default.

Real Problems Reported When Moving Old Compress Archives to 7Z

A documented, historical compatibility issue involves the LZW code-width setting a TZ archive was originally created with: files compressed using a 16-bit maximum can fail to decompress at all on tools expecting a narrower 12-bit or 14-bit ceiling, meaning the conversion has to succeed at reading the source archive first before 7Z's own, unrelated LZMA2 encoding ever becomes relevant.

A second recurring pattern involves users expecting 7-Zip to shrink an already-tiny TZ archive dramatically and being surprised when the size difference is smaller than hoped — this happens specifically with archives holding already-compressed content such as images, where neither LZW nor LZMA2 has much genuine redundancy left to exploit, so the gap between the two algorithms narrows sharply on that kind of data even though it's wide on plain text or source code.

A third issue shows up around Unix permission metadata: tar's header records carry file ownership and permission bits directly, and whether those survive into the rebuilt 7Z depends on whether the specific conversion tool preserves 7Z's optional Unix-attributes extra field, since the base 7Z specification treats that metadata as optional rather than mandatory.

Plain LZW Set Against LZMA2's Larger, Two-Stage Design

Common Questions About Moving a Compress Tarball Into 7-Zip's Format

Can 7-Zip create a new TZ or tar.Z file if I want to go the other direction?
No. 7-Zip's own documented supported-formats list places Z among formats it can only extract, never create, so it can read an existing TZ archive but has no option to build a new one.

Why is the size difference between my TZ and the resulting 7Z so large?
Compress's LZW coding has no entropy-coding stage and a dictionary capped at 65,536 entries, while LZMA2 adds range coding on top of a dictionary that can reach tens of megabytes — a substantial, structural gap rather than a marginal one.

Will an old TZ file always be readable, or can it fail before conversion even starts?
It can fail if the archive was created with a wider LZW code width than the reading tool supports, a documented compatibility gap tied to the -b bit-width setting used when the original file was compressed.

Does converting to 7Z let me password-protect the archive?
Yes. 7Z supports optional AES-256 encryption of both file contents and filenames, a feature compress has no equivalent for at all.

Does my Mac open 7Z files the same way it opens a TZ file?
Not natively for either, in practice: Apple's Archive Utility feature list doesn't name .7z, .tz, or .taz directly, so a separate tool such as The Unarchiver or Keka is generally needed for both sides of this conversion on macOS.