Convert Any File to Z Online (Repacking Into the 1984 Unix Compress Format)

Choosing a Compression Format That Predates Almost Everything Else Still in Use

Turning a file into a .Z archive means running it through the Unix compress algorithm, LZW-based compression first implemented by Spencer Thomas in 1984 and finalized as version 4.0 by Joseph Orost and collaborators in 1985. Unlike converting to ZIP, TAR.GZ, or 7Z, this is one of the few conversions on this kind of tool where the destination format is genuinely older than most of the source formats it might be converted from, since LZW-based compress predates gzip, bzip2, and every archive format built after the mid-1990s.

A .Z file can only ever hold one compressed file, with no folder or multi-file structure of its own, so converting several files into this format at once generally means bundling them with TAR first, producing a .tar.Z file, exactly the same two-step pattern used for .tar.gz or .tar.xz today, just with a different, older compression algorithm applied in the second step.

Producing a .Z file from something that was never a Unix-native format at all — an image, a spreadsheet, a document — works the same way any other single-file compression conversion does: the file's bytes go in as one continuous stream, and compress's LZW encoding runs over that stream without caring what kind of data it originally represented. The algorithm has no awareness of file types; it only ever looks for repeated byte sequences, which is why compress works identically well, or poorly, regardless of whether the input happens to be a text file, a binary program, or something else entirely.

What LZW Actually Does to Your Data During This Conversion

Compress's LZW implementation scans the input and builds a dictionary of byte sequences it has already seen, replacing repeated sequences with shorter codes pointing back into that dictionary rather than storing the repeated bytes again. It starts with 9-bit codes and grows the code width adaptively as the dictionary fills, typically up to a maximum of 16 bits, which the file's own header records so a decompressor knows exactly how the encoding was configured. This is meaningfully different from the DEFLATE algorithm most modern tools default to, which combines a sliding-window LZ77 match stage with Huffman coding rather than LZW's dictionary-code approach, and it's also different from LZMA2, which uses a much larger dictionary window and range coding instead.

One specific technical safeguard built into the format is worth knowing if you're producing files for an older or unfamiliar decompressor: compress writes a fixed two-byte magic number at the very start of every .Z file, immediately followed by a flag byte that records the maximum code width used during that specific compression run. A decompressor reads this header first and refuses to proceed if the magic number doesn't match, which is a built-in sanity check against feeding it a file that was never actually compress output in the first place, and it's also why a .Z file can't simply be renamed from something else and expected to decompress correctly.

Because LZW's dictionary approach and DEFLATE's LZ77-plus-Huffman approach are structurally different algorithms rather than variations on the same idea, the actual compressed output size for the same input file is very unlikely to match between the two — and on most typical files, DEFLATE, and especially LZMA2, will compress noticeably tighter than the older LZW-based compress does, a real, measurable ratio difference rather than a stylistic quirk of the older format.

What Creating a New .Z File Gains and Costs Today

• Lose — meaningfully better compression than gzip or XZ would give: LZW's simpler dictionary coding generally compresses less tightly than DEFLATE or LZMA2 on the same data.
• Gain — compatibility with genuinely ancient decompression tools: some very old Unix systems and archived toolchains from the 1980s and 1990s can decompress .Z but were never updated to understand gzip or newer formats.
• Lose — the patent-free assurance modern formats offer by design: while the LZW patent expired in 2003 and is no longer a legal concern, the format's whole history is tied to a patent dispute that shaped why it was abandoned in the first place.
• Unchanged — the underlying file's actual content: LZW compression, like any lossless algorithm, doesn't discard any data; decompressing later restores the file exactly.
• Gain — matching a specific legacy system's expected format: a small number of specialized industrial, academic, or archival systems from the compress era still specifically expect this format for compatibility with existing scripts or hardware.

Which Current Tools Actually Still Write This Format

Modern operating systems generally still support reading .Z files even though very few tools default to creating new ones. On Linux, the ncompress package and certain gzip distributions retain a compress-compatible mode for creating .Z output, while 7-Zip on Windows and The Unarchiver on macOS focus on extraction rather than creation, treating .Z largely as a read-only legacy format at this point. This asymmetry between broad decompression support and narrow, mostly command-line-only compression support is itself a real, documented sign of how thoroughly gzip and later formats displaced compress as an actively chosen default, decades before any patent issue with LZW was even resolved.

Choosing to output .Z today is essentially always driven by a specific downstream requirement rather than any technical advantage — matching what an existing legacy pipeline, archival system, or academic dataset format already expects — rather than picking it for better compression, faster processing, or broader current compatibility, since gzip and XZ both outperform it on every one of those dimensions for a general-purpose use case.

The Real Reason People Ask for This Conversion at All

A recurring, documented reason someone specifically needs to produce a new .Z file today is working with an older scientific, geospatial, or industrial dataset pipeline that was built decades ago around compress and has never been fully modernized, where every downstream script, parser, or piece of specialized hardware firmware still expects that exact extension and encoding rather than gzip's DEFLATE output. Replacing the entire pipeline is often more expensive or risky than simply producing files in the format it was originally built to expect, which is the actual, practical justification for creating .Z output rather than any belief that the format itself is technically preferable.

A second, less common but real scenario involves academic archive preservation projects deliberately reproducing files in their original historical format, including compress output, specifically to test or document how period-appropriate software handled that data, rather than for any practical compression benefit — a use case where matching the old format exactly is the actual point of the exercise.

A third pattern shows up in cross-platform scripting environments that were originally written for older Unix or Linux systems and that call the compress binary directly, by name, rather than relying on a general-purpose compression library. Reproducing a .Z file lets those scripts keep running unmodified inside a translation or migration project, buying time to eventually rewrite the automation to call gzip or another modern tool instead, without forcing that rewrite to happen before the migration itself can proceed.

LZW Dictionary Coding Set Beside the Compression Formats That Replaced It

Common Questions About Producing a New Compress-Format File

Is there any benefit to using .Z instead of .gz today?
Almost never for general use. Gzip's DEFLATE algorithm generally compresses better than the older LZW-based compress format, and far more current software writes .gz by default. The main reason to choose .Z is compatibility with an existing legacy system that specifically expects it.

Will converting my file to .Z lose any data?
No. LZW compression, like gzip's DEFLATE or XZ's LZMA2, is lossless, meaning decompressing the result later restores the exact original file with nothing discarded.

Can I bundle multiple files into one .Z archive?
Not directly. The format only compresses a single file, so multiple files need to be combined with TAR first, producing a .tar.Z file, the same pattern used for .tar.gz or .tar.xz.

Is the old LZW patent still a concern for using this format?
No. The U.S. LZW patent, originally granted to Sperry Research Center and later enforced by Unisys, expired in 2003 and is no longer a legal restriction anywhere.

Why does my file barely shrink after converting it to .Z?
LZW's dictionary-based approach doesn't find and exploit repetition as effectively as DEFLATE or LZMA2 do on most typical files, so a .Z file is often noticeably larger than the same content compressed with gzip or XZ.