What Is a .TZO File? (A Tarball Compressed With the LZO Algorithm)

Where the TZO Extension Actually Comes From

A .tzo file is a tar archive compressed with lzop, a compression utility built around Markus Oberhumer's LZO (Lempel-Ziv-Oberhumer) compression library. The extension itself is a documented shorthand: lzop's own manual describes .tzo as a substitute for .tar.lzo, used specifically in situations where the longer, more descriptive double extension would be awkward or unsupported on a particular filesystem. Functionally, a .tzo file and a .tar.lzo file are the exact same thing — a plain tar archive that has had lzop's LZO-based compression applied to the whole finished tar stream, the same two-step tar-then-compress pattern used by .tar.gz, .tar.bz2, and .tar.xz.

LZO itself, and by extension lzop, was designed with a specific, narrow goal that sets it apart from gzip, bzip2, or xz: rather than trying to shrink a file as much as possible, LZO prioritizes compression and especially decompression speed above almost everything else, at the direct cost of a noticeably weaker compression ratio than those other formats typically achieve on the same data.

The underlying tar layer works exactly the same way it does with any other compressor: tar itself stores each file as a header block recording its name, permissions, and size, immediately followed by that file's raw data, one entry after another in one continuous stream, with no built-in index of what's inside. Whatever compression method eventually gets applied — lzop, gzip, bzip2, or xz — wraps around that finished tar stream as a separate step, which is exactly why a .tzo file needs to be decompressed all the way back to plain tar before any of its individual files can be extracted.

The Speed-First Trade-Off Built Into LZO's Design

Lzop's default compression method, lzo1x_1, is a straightforward Lempel-Ziv-style scheme deliberately kept simple to decode: rather than the multi-pass entropy coding steps that gzip's DEFLATE, bzip2's Burrows-Wheeler Transform, or xz's LZMA2 all perform, LZO's decompression path involves comparatively little computation per byte, which is exactly why it decompresses dramatically faster than those alternatives. Independent compression benchmarks that pit lzop against compress, gzip, bzip2, and lzma/xz consistently show lzop finishing near the front on raw speed while trailing all of them on how small the output actually ends up.

That speed advantage is dramatic enough to matter in real workflows: lzop has been documented compressing an entire Linux kernel source tree in around one second, a task that takes measurably longer with gzip and far longer with bzip2 or xz at their higher settings. For any workflow where the compression or decompression step itself sits directly in a time-critical path — booting a device, provisioning a system, or running inside a tight backup window — that speed difference isn't a minor convenience, it's the entire reason LZO gets chosen over a format that would otherwise produce a smaller file.

Lzop's file format also builds in a specific, documented integrity feature: each compressed block carries a checksum, using Adler-32 by default or CRC-32 if the --crc32 option is specified instead, and a --no-checksum option exists to skip this step entirely for a small additional speed gain. As lzop's own documentation states plainly, these checksums only detect data corruption — they can't correct it — so a checksum mismatch on extraction tells you the data is damaged without providing any way to repair it from that information alone.

Why Embedded Linux Systems Adopted This Specific Trade-Off

• Boot-time decompression speed matters more than storage size on many embedded devices: routers and other OpenWrt-style embedded Linux hardware historically favored LZO-based compression for kernel images and filesystems specifically because decompression happens on every boot, on comparatively weak CPUs.
• Weaker compression ratio is an accepted cost, not an oversight: LZO produces meaningfully larger output than gzip or xz on the same data, a deliberate trade embedded projects made in exchange for faster decompression on limited hardware.
• Low CPU and memory overhead suits constrained hardware: LZO's simpler algorithm needs less working memory and CPU time than LZMA2 or even DEFLATE, which matters on devices with only a few megabytes of RAM.
• Real-time and near-real-time compression use cases exist beyond embedded systems too: LZO-family algorithms get used anywhere compression can't afford to become the performance bottleneck, including some backup tools and certain database or filesystem compression layers.
• None of this changes what tar itself stores: the underlying tar container inside a .tzo file records the same file names, permissions, and structure regardless of which compressor gets applied on top of it.

Which Tools Actually Read and Write This Format

Creating or extracting a .tzo file requires the lzop command-line tool itself, or a library built on the same LZO code, since this compression scheme sits well outside what general-purpose archive managers support by default. GNU tar has direct built-in support for it through its --lzop flag, or equivalently through --use-compress-program=lzop on systems where the shorter flag isn't available, which invokes the external lzop binary to handle the compression step while tar handles the archiving step. 7-Zip, WinRAR, and most mainstream Windows and macOS archive tools do not support LZO-based compression natively, which is a real, documented compatibility gap compared with gzip, bzip2, or xz, all of which those same tools do handle without extra software.

This narrower tool support is itself informative: .tzo files are overwhelmingly created and consumed within Linux and embedded-systems contexts where lzop is already installed as part of a specific toolchain, rather than in general file-sharing situations where a recipient might be using an unfamiliar operating system. Anyone receiving a .tzo file from an unfamiliar source should expect to need the lzop package specifically, not assume a general-purpose archive tool will already understand it.

Package managers make lzop easy enough to add where it's missing — it's available directly through apt on Debian and Ubuntu, dnf or yum on Fedora and RHEL-based systems, and Homebrew on macOS — so the compatibility gap compared with gzip or ZIP is really about default installation, not availability. A system that doesn't already have lzop installed for another reason typically doesn't have it sitting there by chance, which is a real, practical difference from gzip and ZIP support being baked into the operating system itself.

The Actual Confusion People Run Into With This Format

A recurring point of confusion involves the naming overlap between LZO the compression library and LZ4, a separate, also speed-focused compression algorithm that gets discussed in many of the same embedded-systems and kernel contexts. They are different algorithms from different authors with different implementations, even though both prioritize decompression speed over compression ratio and both show up in similar embedded and real-time use cases — mixing them up leads to confusion about which specific tool or library a given .tzo file actually needs.

A second real issue shows up around the checksum lzop embeds by default: because Adler-32, the default checksum algorithm, is weaker at detecting certain kinds of corruption than CRC-32, some backup and archival workflows specifically document switching to the --crc32 option for anything considered important enough to need stronger corruption detection, rather than relying on lzop's out-of-the-box default setting.

A third documented complaint involves file-transfer or storage systems with strict extension allowlists that recognize common double extensions like .tar.gz but reject the shorter .tzo extension outright as unrecognized, even though the archive itself is perfectly valid. Since .tzo and .tar.lzo describe the identical format, renaming the file to the longer, more descriptive .tar.lzo spelling sometimes clears an extension filter like this without touching the file's actual contents at all.

LZO-Based Compression Set Beside Gzip's More Common DEFLATE

Common Questions About Opening and Creating TZO Archives

What software do I need to open a .tzo file?
The lzop command-line tool, or GNU tar used with its --lzop flag, which calls lzop internally. Most general-purpose archive managers like 7-Zip or WinRAR do not support this compression method natively.

Is .tzo the same thing as .tar.lzo?
Yes. Lzop's own documentation describes .tzo as a shorthand substitute for the longer .tar.lzo extension, used on the exact same underlying format.

Why would anyone choose this over gzip if it compresses worse?
Because LZO is built specifically for decompression speed, not ratio. On embedded devices or time-critical workflows where fast decompression matters more than a smaller file, that trade-off is worth it.

Is LZO the same thing as LZ4?
No. They're separate compression algorithms from different developers, though both share a similar speed-over-ratio design goal and both show up in comparable embedded-systems contexts, which is a common source of confusion.

Does lzop check for file corruption?
Yes, using an Adler-32 checksum by default or CRC-32 if requested with the --crc32 option. Per lzop's own documentation, this only detects corruption; it can't repair it.