TAR.LZO File — What It Is and Why Speed Was the Only Goal

A Tar Archive Wrapped in the Fastest Common Compressor Available

A .tar.lzo file is a tar archive — files bundled together with 512-byte header blocks recording each entry's name, owner, permissions, and size — that has then been compressed as a separate step using lzop, the command-line utility built around Markus Oberhumer's LZO compression library. Oberhumer released the original lzop implementation on August 10, 1997, built on LZO algorithm work he had been developing since around 1996. Tar and lzop know nothing about each other's internal logic, exactly the same separation that exists between tar and gzip in a .tar.gz file; tar's only job is grouping files, and lzop's only job is shrinking whatever continuous byte stream tar hands it afterward.

LZO's entire design goal, stated directly in its own documentation, is favoring decompression speed above almost everything else, including the resulting file size. Its default compression method, lzo1x_1, performs a comparatively simple Lempel-Ziv-style scan that replaces repeated byte sequences with shorter back-references, skipping the additional entropy-coding stage that gzip's DEFLATE and most other general-purpose compressors add on top of their own LZ77-style matching. Removing that stage is precisely why LZO compresses less tightly than gzip or bzip2 on typical data, but decompresses meaningfully faster than either, since there's simply less decoding work left to do once the LZ-style matching is undone.

The Documented Byte Signature Every LZO-Compressed File Starts With

Every file lzop produces begins with a fixed nine-byte magic sequence — 0x89 0x4C 0x5A 0x4F 0x00 0x0D 0x0A 0x1A 0x0A in hexadecimal — a signature deliberately modeled on the same style of magic-byte design PNG uses, mixing a high-bit byte, the ASCII letters "LZO," and specific line-ending bytes chosen to make the format easy to detect reliably and to fail loudly if it's accidentally transferred through a text-mode channel that mangles line endings. Immediately following that signature, lzop's header records a version number, the specific LZO compression method and level used, and file metadata including the original file's name, timestamp, and Unix permission bits.

Unlike gzip, which computes a single CRC-32 checksum covering the entire decompressed stream, lzop's own documentation describes a block-based structure: the compressed data is split into blocks, and each block carries its own checksum, using the faster Adler-32 algorithm by default or CRC-32 if the stronger --crc32 option is explicitly requested when the file is created. Both lzop's own manual and its documentation state plainly that this checksum can only detect corruption, not repair it — a limitation shared with gzip's simpler single-checksum design, just applied at a finer, per-block grain instead of once for the whole file.

The LZO library itself, and the lzop utility built on it, are both released under the GNU General Public License, version 2 or later — a copyleft license, unlike zlib's considerably more permissive licensing terms for the code behind gzip and DEFLATE. That licensing difference has been a documented, real consideration for some proprietary embedded-firmware projects choosing between LZO and other fast compressors, since GPL code carries redistribution obligations that a more permissively licensed alternative wouldn't.

Lzop's own manual also documents several selectable compression levels beyond the default lzo1x_1, ranging up to a much more thorough lzo1x_999 method invoked with the --best flag, which spends considerably more time searching for matches in exchange for a somewhat smaller output file. Even at its most thorough setting, LZO still omits the entropy-coding stage that gzip and bzip2 both apply, so --best narrows the ratio gap without ever fully closing it, and decompression speed stays essentially unaffected by which compression level was used to create the file in the first place.

What Choosing LZO's Speed Priority Gains and What It Gives Up

• Gain — extremely fast decompression: LZO's simplified matching, with no entropy-coding stage, decompresses faster than gzip, bzip2, or xz on comparable hardware.
• Gain — very low memory and CPU overhead: LZO's lighter algorithm suits constrained embedded hardware that can't spare much processing power or RAM for compression tasks.
• Lose — compression ratio compared with gzip, bzip2, or xz: skipping the entropy-coding stage that those formats add leaves more redundancy in the compressed output.
• Gain — per-block checksums instead of one whole-file checksum: lzop's block structure means a single damaged block doesn't necessarily prevent reading the rest of the file.
• Lose — mainstream desktop software support: 7-Zip, WinRAR, and Windows/macOS's built-in tools generally don't include native LZO decompression at all.

Where the Linux Kernel Itself Relies on This Same Algorithm

LZO's speed priority isn't just a tar-compression footnote; it's built directly into the Linux kernel in several places where fast decompression genuinely matters more than file size. The kernel's zram subsystem, which creates a compressed block device living in RAM to reduce disk paging, documents LZO as one of its selectable compression backends specifically for this speed-sensitive use case. SquashFS, the read-only compressed filesystem format used in many Linux live images and embedded systems, gained LZO compression support in kernel version 2.6.34. Btrfs, the copy-on-write filesystem, also documents LZO as one of its three supported compression algorithms alongside zlib and zstd, noting that LZO doesn't support adjustable compression levels the way the other two do and that its compression speed is generally fast enough to keep pace with the storage medium itself.

Outside the kernel, .tar.lzo and its shortened cousin .tzo show up specifically in embedded Linux firmware images and router operating systems such as OpenWrt, where a bootloader with very limited processing power needs to decompress a boot image as quickly as possible, and every extra second of decompression time delays the device actually starting up.

Backup software aimed at large datasets has also documented LZO as a selectable fast-compression option specifically for backup windows where the job needs to finish within a fixed overnight time slot, trading some storage efficiency for a compression and decompression pass fast enough to reliably complete before that window closes, rather than risking a backup job that's still running when the next business day begins.

The Real, Documented Reasons a TAR.LZO File Won't Open Somewhere

A recurring, documented complaint involves someone on Windows or macOS trying to open a .tar.lzo file with 7-Zip or WinRAR and finding it isn't recognized at all — this isn't file corruption; mainstream desktop archive tools on those platforms generally don't build in native LZO decompression, since the format is used almost exclusively in Linux, Unix, and embedded contexts where lzop or GNU tar's --lzop flag is already available specifically for this purpose.

A second recurring issue involves confusion between .tar.lzo and .tzo — lzop's own documentation treats the shortened form purely as an alternate spelling of the identical format, the same relationship .tgz has to .tar.gz, so a script or upload form checking file extensions should accept both spellings as equivalent rather than requiring one specific form.

A third, more procedural pattern shows up in build scripts and Makefiles written for a specific embedded-Linux build system that hardcode a call to lzop or GNU tar's --lzop flag as one fixed step in an image-building pipeline — swapping the underlying tar archive's contents is straightforward, but swapping the compression method used at that stage generally requires updating the script itself, since tar needs to be told explicitly which decompressor to expect rather than guessing from the file alone in every implementation.

TAR.LZO Set Beside the More Common Ways to Compress a Tar Archive

Common Questions About What a TAR.LZO File Actually Is

Is a .tar.lzo file the same as a .tzo file?
Yes. Lzop's own documentation treats .tzo purely as a shortened alternate spelling of the identical format, with no technical difference between the two whatsoever.

Why would anyone choose LZO over gzip if it compresses less?
Because LZO's design goal is fast decompression above nearly everything else, which matters far more than file size in embedded firmware, boot images, and kernel-level uses like zram where speed is the actual constraint.

Do I need special software to open a .tar.lzo file?
Yes, on most desktop systems. The lzop utility or GNU tar's --lzop flag is needed, since mainstream tools like 7-Zip and WinRAR generally don't include native LZO support.

What does the LZO checksum actually protect against?
It can detect that a block of compressed data has been corrupted, but it can't repair the damage — the same limitation gzip's own single checksum has, just applied per block instead of once for the entire file.

Where is LZO used outside of tar archives?
Directly inside the Linux kernel, including the zram compressed-RAM block device, SquashFS since kernel version 2.6.34, and as one of Btrfs's three supported filesystem compression algorithms.