Convert TAR.Z to TAR Online (Reversing the Very First Tarball-Plus-Compression Pairing)
Since the full extension already confirms a tarball is inside, this conversion is one clean mechanical step — removing LZW compression using its documented header.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
Why the Full ".tar.Z" Spelling Already Settles What's Inside
A file named with the complete ".tar.Z" extension, rather than a shortened form like .tz or .taz, already confirms unambiguously that a tar archive is what's underneath the compression layer — there's no need to first determine whether a single file or a bundled archive was compressed, the way there sometimes is with a bare ".Z" extension on its own. Compress, implemented by Spencer Thomas in 1984 and finalized as version 4.0 in 1985, can only ever shrink one file at a time, which is exactly why building a .tar.Z archive in the first place always meant running tar first to bundle everything, then compress second to shrink the finished result.
Reversing that pairing back to plain .tar means undoing only the second half of that two-step process: a decompressor checks the file's fixed magic bytes, 0x1F followed by 0x9D, confirms the file is genuine compress output, reads the following byte to determine the maximum LZW code width that was used, and then reconstructs the original tarball by reversing the dictionary substitution compress applied. Nothing about tar's own file list, folder structure, or Unix permission bits is touched by this step, since compress's compression operated purely on the finished byte stream tar had already produced.
GNU tar handles both steps together automatically through its -Z flag, or through the more general -a auto-detection option, which reads the file's extension or header bytes to pick the right decompressor without requiring the user to specify compress explicitly.
What the Header Byte Actually Tells the Decompressor to Do
The third byte in every .tar.Z file's header carries two separate pieces of information packed into one value: its high bit, checked with the mask 0x80, indicates whether the file uses block compress mode, and its remaining five bits, checked with the mask 0x1F, record the maximum code width, typically 16, that the original compression used. A decompressor has to read this byte correctly rather than assuming a fixed setting, since older or more constrained systems occasionally capped that maximum lower, and getting it wrong means misinterpreting the dictionary the file's compressed data is built around.
Block compress mode specifically affects how the reversal has to proceed: files built with block mode enabled include a special clear code partway through the compressed stream whenever the original compression ratio dropped enough to warrant resetting the dictionary, and a decompressor has to recognize that clear code and reset its own dictionary-rebuilding process at exactly the same point to correctly reconstruct the data that follows. Getting this synchronization wrong doesn't corrupt the whole file, but it does break decompression from that specific point onward.
Once this LZW reversal completes successfully, what's left is the plain tar stream exactly as it existed before compress ever touched it — tar's own 512-byte-aligned header blocks, describing each file's name, permissions, and size, followed immediately by that file's actual data, with nothing about that internal structure altered by having spent time wrapped in LZW compression.
What This Specific Reversal Restores and What It Drops
- Lose — whatever size reduction LZW was providing: even though LZW compresses less aggressively than newer algorithms, it still meaningfully shrinks most files, so removing it makes the recovered tarball noticeably bigger.
- Gain — a file readable by absolutely anything that understands tar: plain .tar has been openable on every Unix-family system since the 1980s, with no LZW decoder needed at all.
- Unchanged — every filename, folder path, and Unix permission bit: tar's own header structure passes through this step completely intact, since compress never modified it in the first place.
- Lose — the compress magic-number header's built-in sanity check: that check, letting a decompressor confirm valid compress input before proceeding, no longer applies once the file is plain tar.
- Gain — compatibility with tools that reject .Z outright: some current intake systems and upload forms recognize .tar but flatly refuse the older, less common .Z extension.
- Lose — the case-sensitive naming convention compress deliberately chose: the capital Z that distinguished compress output from pack's older lowercase-z files becomes irrelevant once the extension is simply .tar.
Where This Exact Reversal Still Gets Used on Purpose
On the commercial Unix systems that still ship compress as standard tooling — Oracle Solaris and illumos, IBM AIX, and HP-UX — administrators occasionally need to reverse this exact pairing specifically to inspect or modify an archive's contents before recompressing it, since editing files inside a tarball requires the archive to be in its plain, uncompressed form first; tools that add, remove, or alter entries inside a tar archive work against tar's own header structure directly and can't operate on a compressed LZW stream.
A second genuine use case involves migrating an old .tar.Z archive to a newer compression format entirely: converting to .tar.gz or .tar.xz always passes through a plain, uncompressed .tar file as the necessary middle step, since neither gzip nor xz can convert LZW-compressed data directly into their own compressed format without first returning to the uncompressed tarball underneath.
A third scenario shows up in digital preservation work specifically: some institutions handling decades-old .tar.Z archives from legacy Unix backups or academic dataset distributions deliberately decompress them to plain tar as a documentation and verification step, confirming the archive's actual contents are intact and readable before deciding whether to keep the original LZW-compressed form, recompress with a modern algorithm, or store the plain tar version going forward.
The Real Cause Behind "My Decompressed File Looks Wrong Partway Through"
A documented, specific issue reported when decompressing certain old .tar.Z files involves the block-mode clear code not being handled correctly by a particular decompression tool, producing garbled or truncated data starting from wherever that dictionary reset occurred in the original compressed stream, even though everything before that point decompresses correctly. The fix reported in these cases is switching to a decompressor with more thoroughly tested block-mode support, such as gzip's own bundled uncompress command or a current build of 7-Zip, rather than assuming every tool handles this less commonly exercised part of the format identically.
A second real pattern involves the code-width byte specifically: a handful of very old .tar.Z files were built on systems that capped the maximum LZW code width lower than the common 16-bit default, and a decompressor that assumes the more typical setting instead of actually reading that byte from the file's own header can misinterpret those specific archives, producing an error or corrupted output rather than a correctly reconstructed tarball.
A third issue involves disk space during this exact reversal: since the recovered plain .tar file is meaningfully larger than the compressed .tar.Z it came from, decompressing a large archive without checking available disk space ahead of time can run a system out of storage partway through, a straightforward but easily overlooked planning gap for anyone handling sizable legacy archives.
LZW-Wrapped Tarball Set Beside Its Recovered Plain Form
| Feature | TAR.Z | TAR (recovered) |
|---|---|---|
| Compression layer | LZW via compress | None |
| Header verification | Magic bytes 0x1F 0x9D plus code-width byte | None built in |
| Typical file size | Smaller | Larger, close to original data size |
| Direct in-place editing of contents | Not practical while compressed | Straightforward with standard tar tools |
| Required decoder to open | A compress-aware tool | Any tar-aware tool since the 1980s |
| Extension case sensitivity | Capital Z deliberately significant | Not applicable |
Questions About Reversing the Compression Half of an Old Tarball
Why is my recovered .tar file bigger than the .tar.Z I started with?
Because LZW compression was genuinely shrinking the file, even though it's less effective than modern algorithms. Removing it restores the original tarball's size, which is expected, not an error.
Does this conversion lose any files inside the archive?
No. Tar's file list, folder structure, and Unix permission bits pass through completely unchanged, since compress only ever touched the compressed byte stream, never the archive structure itself.
What are the exact bytes a decompressor checks before proceeding?
The fixed magic number 0x1F followed by 0x9D, then a byte whose bits record the block-mode flag and the maximum LZW code width the original file used.
Why would I want a plain .tar file instead of keeping it compressed?
Mostly as an intermediate step — editing files inside the archive, or recompressing it with gzip or xz, both require passing through plain, uncompressed tar first.
Can a decompression tool get confused by the code-width byte?
Yes, on some very old files. A handful were built with a lower maximum code width than the common default, and a tool that assumes the typical setting instead of reading that byte can misinterpret them.
Do I need to check disk space before decompressing a large .tar.Z file?
It's worth doing for sizable archives, since the recovered plain .tar file will be meaningfully larger than the compressed original, and running out of storage partway through the decompression is a documented, avoidable problem.