Convert TZO to TAR Online (Stripping Out lzop's LZO Compression Layer)

What a .TZO File Actually Wraps Around

A .tzo file is a plain tar archive that has had lzop's LZO-based compression applied to the entire finished tar stream. Lzop's own documentation describes .tzo as a shorthand for .tar.lzo, used in place of the longer double extension — both refer to the exact same underlying file. Converting a .tzo file to plain .tar means removing that LZO compression layer entirely and leaving behind the uncompressed tar archive that was there all along, unmodified in structure, just larger in size and no longer run through lzop at all.

This is worth stating plainly because it's the simplest possible conversion in this entire category: unlike converting between two different compression algorithms, or between two entirely different container formats, going from .tzo to .tar involves no re-encoding of file contents into a different scheme at all — it's strictly a decompression step, full stop, with nothing rebuilt or reformatted afterward.

LZO itself comes from Markus Oberhumer's Lempel-Ziv-Oberhumer compression library, and lzop is the command-line utility built around it, first released to give that library a practical, tar-friendly compression tool. LZO's whole design centers on decompression speed rather than compression ratio, which is why it turns up in embedded Linux firmware, router operating systems like OpenWrt, and backup pipelines where unpacking data quickly matters more than shrinking it as much as possible — context that explains why a .tzo file exists in the first place, even though this particular conversion undoes that choice entirely.

Why Tar Itself Never Changes, Whichever Compressor Wraps Around It

Tar, short for "tape archive," is a sequential container format originally designed for writing data to magnetic tape. Each file inside gets a 512-byte header block recording its name, permissions, ownership, and size, immediately followed by the file's own data, padded out to the next 512-byte boundary, with entries simply following one another in order and no built-in index of what's inside or where anything sits. This structure has stayed essentially unchanged since tar's earliest design, regardless of which compression tool, if any, gets layered on top of the finished stream afterward.

LZO compression, applied by lzop, treats that entire finished tar stream as one continuous sequence of bytes to compress, with no awareness of the tar headers or file boundaries inside it — it's a general-purpose compressor bolted onto the outside of an already-complete archive, not something integrated into tar's own format. This is exactly why removing the LZO layer via decompression restores the tar stream to precisely the state it was in right before compression happened, byte for byte, with the same headers, the same file order, and the same padding.

The practical result of stripping that compression layer is straightforward and predictable: the resulting .tar file will be larger than the .tzo file it came from, generally by whatever ratio LZO's specific compression achieved on that particular data, which tends to be a more modest reduction than gzip, bzip2, or xz typically achieve, since LZO trades compression ratio for decompression speed by design.

What Removing LZO Compression Gains and Costs

• Gain — universal tar tool compatibility: a plain .tar file needs no LZO-aware software at all to extract, since every tar implementation everywhere understands the base format.
• Lose — the storage-space savings LZO provided: a plain tar archive is always larger than the equivalent LZO-compressed .tzo file, since nothing is compressed anymore.
• Gain — direct editability with basic tools: some tar-manipulation utilities can append to or modify an uncompressed tar archive more easily than a compressed one, which generally requires full decompression first anyway.
• Lose — LZO's built-in checksum protection: lzop embeds an Adler-32 or CRC-32 checksum per compressed block; a plain tar file has no equivalent compression-layer integrity check once that layer is removed.
• Unchanged — every file's actual content, name, and permissions: nothing about the tar structure itself changes; this conversion only removes the compression wrapped around it.

Documented Support for Reading Both Compressed and Plain Tar

Reading the original .tzo file requires the lzop utility specifically, or GNU tar invoked with its --lzop flag, which calls lzop internally to handle decompression before tar itself reads the resulting stream — mainstream Windows and macOS archive managers generally don't include LZO decompression support by default, which is a real, current limitation compared with how those same tools handle gzip or bzip2.

A plain .tar file, once the LZO layer is gone, needs nothing beyond standard tar support, which is essentially universal: GNU tar on Linux, bsdtar on macOS and BSD systems, and 7-Zip or PeaZip on Windows all read plain tar archives without any additional compression-specific tooling. This is precisely the appeal of stripping compression away entirely in some workflows — the resulting archive becomes trivially readable by anything, at the direct cost of taking up more disk space than it did while compressed.

Tar's format has also barely changed since its earliest specification, and the POSIX ustar standard that most modern tar implementations follow has been stable for decades, which is part of why a plain tar file is considered a safer long-term bet for readability than any specific compressed variant — the compression tool needed to open a .tzo, .tar.gz, or .tar.bz2 file could theoretically fall out of common use someday, but tar's base header format is unlikely to become unreadable in the same way.

Why Anyone Actually Wants an Uncompressed Tarball

A documented, recurring reason to strip compression away entirely involves further processing steps that need to inspect or modify individual files inside the archive without paying a repeated decompression cost each time — build systems and automated pipelines that read the same archive's contents multiple times sometimes decompress once up front specifically to avoid re-running LZO decompression on every single pass through the data.

A second real scenario involves compatibility troubleshooting: when a .tzo file fails to open on an unfamiliar system because that system lacks lzop or LZO-aware tooling entirely, decompressing it on a system that does have lzop installed and distributing the plain .tar file instead sidesteps the missing-tool problem completely, at the cost of a larger file to transfer.

A third pattern shows up in archival and long-term storage contexts where an organization specifically wants to avoid depending on any particular compression algorithm remaining available or well-supported decades into the future, choosing to store data as plain tar precisely because the format's simplicity makes long-term readability more certain than betting on a compression tool's continued support, even one as lightweight and portable as lzop.

A fourth, more everyday reason involves recompressing the same content with a different algorithm entirely — someone who wants to switch a .tzo archive to gzip, bzip2, or xz for better compatibility or a tighter ratio typically has to pass through this exact plain-tar intermediate state anyway, since none of those tools understand LZO-compressed input directly. Producing the plain .tar file as its own explicit step, rather than trying to jump straight from one compressed format to another in a single operation, is often the more transparent and easier-to-troubleshoot way to handle that kind of format migration.

LZO-Compressed TZO Set Beside Uncompressed Plain TAR

Common Questions About Removing LZO Compression From a Tarball

Does converting from .tzo to .tar change any of my files?
No. This conversion only removes the LZO compression layer; the underlying tar structure, file names, permissions, and contents remain exactly the same.

Why would I want an uncompressed tar file instead of the smaller .tzo?
Mainly for universal compatibility, since any system with basic tar support can read a plain .tar file without needing lzop or LZO-aware tooling installed at all.

Is .tzo the same as .tar.lzo?
Yes. Lzop's own documentation describes .tzo specifically as a shorter substitute for the .tar.lzo extension, referring to the identical format.

How much bigger will my file get after this conversion?
It depends on how compressible the original data was, but expect a moderate size increase, since LZO's compression ratio is generally weaker than gzip, bzip2, or xz to begin with.

Do I lose the checksum protection lzop provided?
Yes. Lzop's per-block Adler-32 or CRC-32 checksums are part of the compression layer being removed; a plain tar file has no equivalent built-in integrity check of its own.

Should I convert to plain tar before switching to gzip or xz instead?
It can help. Since gzip, bzip2, and xz can't read LZO-compressed data directly, decompressing to plain tar first as its own explicit step is often a clearer way to then recompress with a different algorithm.