Convert Any File to TZ Online (Packaging Arbitrary Files Into a Tar-Plus-Compress Archive)

What Actually Happens When Your Files Become a TZ Archive

A .tz file is a tar archive that has been compressed with the classic Unix compress utility, and the exact same combination is also seen written as .tar.Z or .taz. Building one from scratch out of arbitrary files — photos, documents, source code, or an entire folder tree — is not one operation but two, run back to back. Tar first bundles everything into a single file using 512-byte header records, a layout that has stayed essentially unchanged since Seventh Edition Unix in 1979. Only after that bundling is finished does compress run over the result, shrinking the whole combined stream using the Lempel-Ziv-Welch algorithm first implemented by Spencer Thomas at the University of Utah in 1984 and finalized as version 4.0 in 1985 by Joseph Orost and collaborators.

Because those two steps come from entirely separate programs, the resulting archive carries two distinct signatures stacked on top of each other: tar's own header structure, describing each file's name, size, and Unix permissions, followed immediately by compress's two-byte magic number, 0x1F 0x9D, marking where the LZW-compressed data begins. Nothing about turning a batch of arbitrary files into a TZ archive is a single unified process the way it is with formats designed decades later — it is genuinely two separate legacy tools doing two separate, unrelated jobs.

Why This Is Two Independent Legacy Programs, Not One Format

Tar has no compression logic built into it at all — it only ever concatenates files together with header blocks in between, a design built for writing sequentially onto magnetic tape, where an index or random-access structure would have been useless anyway. Compress, on its own, has no concept of bundling multiple files together either; it takes exactly one input stream and produces exactly one compressed output stream. Packaging several arbitrary files as a TZ archive is only possible because tar's output happens to look, from compress's point of view, like a single ordinary file to shrink.

Compress's LZW encoding starts each new run at 9-bit codes and grows adaptively as it builds a dictionary of previously seen byte sequences, up to a maximum width set by the -b option. The POSIX specification for the compress utility documents that maximum as ranging from 9 to 16 bits, with a default of 14, 15, or 16 depending on the implementation — a real, concrete detail with practical consequences, since a file compressed with a wider maximum code width than an old decompressor supports can fail to decompress on that older system.

This contrasts directly with self-contained archive formats built later: ZIP and 7Z both handle bundling and compression as one integrated process inside a single program and a single file specification, with no equivalent of tar handing off a finished stream to a completely separate compressor afterward. A TZ archive's two-program design is a direct artifact of when it was built — 1979 for tar's structure, 1984-1985 for compress's algorithm — years before any single tool tried to do both jobs at once.

What Building a New TZ Archive Today Gains and What It Costs

• Lose — a smaller resulting file than gzip or newer compressors would give: LZW's simpler, single-pass dictionary coding generally compresses less tightly than DEFLATE, bzip2, or LZMA2 on the same input.
• Gain — an exact match for decades-old pipelines that call compress by name: some legacy scripts, embedded tooling, or archival workflows still expect this specific format rather than anything newer.
• Lose — a straightforward creation path in most current software: the GNU tar manual explicitly recommends against its own -Z/--compress option, describing compress as "by far less effective" than the other compression programs tar supports.
• Unchanged — every bundled file's Unix permissions, ownership, and name: that metadata lives entirely in tar's headers, a job compress never touches regardless of which compressor runs afterward.
• Gain — no patent licensing concern of any kind today: the two U.S. patents once covering the Lempel-Ziv-Welch algorithm used here, 4,464,650 and 4,558,302, have both long since expired.
• Lose — a graphical "create archive" option in most mainstream Windows or macOS software: creating a new TZ generally means using tar and compress directly from a command line rather than a point-and-click archive manager.

Which Current Tools Can Actually Create a New TZ Archive

On Linux, the ncompress package — a free reimplementation of the original compress utility — provides the compress binary most current distributions no longer ship by default, and piping tar's output through it recreates the format directly from a terminal. GNU tar itself still documents a -Z / --compress option in its own manual as of GNU tar 1.35, functioning but explicitly discouraged by that same documentation in favor of gzip, bzip2, or xz.

7-Zip's own documented list of supported formats places Z (the Unix compress format) among the formats it can only extract, not create, so 7-Zip has no built-in way to package files into a new .tz or .tar.Z archive despite reading existing ones without issue. Apple's Archive Utility on macOS lists the plain lowercase .z extension among formats it opens, but doesn't name .tz or .taz specifically among the archive types it can build from scratch, leaving the terminal's own tar and compress-compatible tools as the more reliable path on that platform too.

Windows has no built-in graphical option for creating this format at all. Its command-line tar.exe, built on libarchive and shipped since Windows 10 version 1803, is documented as reading a wide range of compressed tar formats, but creating a genuinely new compress-compatible archive on Windows generally still depends on a separate Unix-compatible toolchain such as WSL or Cygwin rather than anything native to File Explorer.

Real, Documented Problems That Show Up When Building One From Scratch

A well-documented historical compatibility issue involves the maximum LZW code width: a TZ archive created with a 16-bit maximum, the common current default, can fail to decompress on an old system whose compress binary was built with a narrower 12-bit or 14-bit ceiling, since that older decompressor's dictionary table simply isn't large enough to hold codes wider than it was compiled to support. This is a genuine, structural incompatibility tied to the -b option's setting at creation time, not file corruption.

A second recurring complaint involves 7-Zip specifically: users who see 7-Zip open an existing .tz file without trouble reasonably assume the same program can create one, then find no ".tar.Z" or "compress" option anywhere in 7-Zip's own archive-creation menu — the extraction-only limitation documented in 7-Zip's own supported-formats list, not a bug or missing setting.

A third pattern shows up in minimal Docker images and stripped-down Linux containers built without legacy packages: a script that calls "compress" directly by name fails with a plain "command not found" error, since ncompress is frequently left out of slim base images by default and has to be installed explicitly through the container's package manager before that step in an older pipeline can run at all.

Building a TZ Archive Compared With Building a TGZ or ZIP Instead

Common Questions About Packaging Files Into a TZ Archive

Can I create a TZ file on Windows without installing anything extra?
No. Windows has no built-in graphical option for this format, and the command-line tar.exe included since Windows 10 version 1803 is documented mainly for reading compressed tar archives rather than creating new compress-format ones from scratch.

Why doesn't 7-Zip let me compress my files into a .tz archive?
7-Zip's own documented list of supported formats places the Z compress format among the ones it can only extract, not create, so it has no menu option for building a new TZ archive even though it opens existing ones without any issue.

Why is my new TZ file bigger than the same files compressed as a TGZ?
Compress's LZW algorithm is a simpler, older design than gzip's DEFLATE, and it generally produces a less tightly compressed result on the same data, which is a documented, consistent difference rather than a fluke of one particular file.

Is the compress algorithm still covered by patents I need to worry about?
No. The two U.S. patents that once covered the Lempel-Ziv-Welch algorithm compress uses, 4,464,650 and 4,558,302, have both long since expired, so there's no remaining licensing concern with using the format today.

Does it matter whether I name my new archive .tz or .tar.Z?
No. Both spellings, along with the less common .taz, describe the exact same tar-plus-compress combination with no technical difference between them; the choice is purely a naming convention.

Will file permissions and folder structure survive being bundled into a TZ?
Yes. That metadata is recorded entirely in tar's own header records before compress ever runs, so which compressor gets applied afterward has no effect on whether permissions, ownership, or folder structure come through intact.