What Is a .LZO File? (The Format Built for Speed, Not Size)

The Fast, Single-File Format Built Around Markus Oberhumer's LZO Library

A .lzo file is a single file compressed with lzop, the command-line utility Markus Oberhumer built around his own LZO (Lempel-Ziv-Oberhumer) compression library, which he began developing around 1996 and first released as lzop on August 10, 1997. Lzop's documentation is explicit that it works the same way gzip does on a lone file: it compresses exactly one input and produces exactly one compressed output, with no built-in way to bundle several files into a single archive. A directory of files compressed this way needs tar first, producing .tar.lzo, or its documented shorthand .tzo, rather than a bare .lzo.

LZO's whole design goal, stated directly in its own documentation, is favoring decompression speed above almost every other consideration, including how small the resulting file ends up. Its default method, lzo1x_1, performs a comparatively simple Lempel-Ziv-style scan that finds repeated byte sequences and replaces them with back-references, while deliberately skipping the entropy-coding stage — Huffman coding or something equivalent — that most other general-purpose compressors, including gzip's DEFLATE and bzip2, add on top of their own matching pass. Skipping that stage is exactly why LZO decompresses so quickly: there's simply less decoding work left to do once the matching is undone.

The LZO library and the lzop tool built on it are both released under the GNU General Public License, version 2 or later, a copyleft license some proprietary embedded-firmware projects have documented weighing carefully against a more permissively licensed alternative, since GPL code carries redistribution obligations that a project may or may not want to take on.

Independent compression benchmarks that test lzop head-to-head against compress, gzip, bzip2, and lzma/xz on identical input files consistently place it near the front of the field on raw speed and near the back on how small the output ends up — a documented, measurable trade-off rather than a subjective impression. Compressing an entire Linux kernel source tree with lzop has been reported to finish in roughly one second, a task that runs noticeably longer under gzip and substantially longer under bzip2 or xz at higher settings.

Inside the Nine-Byte Signature and Per-Block Checksums That Define This Format

Every file lzop produces opens with a fixed nine-byte magic sequence — 0x89 0x4C 0x5A 0x4F 0x00 0x0D 0x0A 0x1A 0x0A — a signature deliberately modeled on PNG's own magic-byte design specifically so that a corrupted or text-mode-mangled transfer fails loudly and immediately rather than silently producing garbage output. The header that follows the magic bytes records the lzop version, the minimum library version needed to decompress the file, the specific LZO method and compression level used, and metadata carried over from the original input: its filename, modification timestamp, and Unix permission bits.

After that header, lzop splits the compressed payload into a series of blocks rather than one unbroken stream, and gives each block its own checksum — the faster Adler-32 algorithm by default, or CRC-32 instead if the `--crc32` option is set when the file is created. That block-level checksum design means a single damaged block doesn't necessarily prevent recovering data from the rest of the file, a granularity advantage over formats that compute just one whole-file checksum, though like any checksum it can only detect corruption, never repair it.

Lzop also documents higher-effort compression settings beyond its speed-first default, up to a lzo1x_999 method reachable through the `--best` flag, which spends more CPU time searching for better matches and narrows, but never eliminates, the ratio gap against DEFLATE or LZMA-based compressors. Even at its most thorough setting, LZO still skips the entropy-coding stage those formats apply, which is why its compression ceiling stays below what gzip or 7-Zip routinely achieve on the same data.

What This Speed-First Format Never Included

• No multi-file bundling: a bare .lzo file holds exactly one compressed stream; combining several files requires tar first, producing .tar.lzo or .tzo instead.
• No entropy coding by default: lzop's default lzo1x_1 method skips the Huffman-style coding stage that gzip, bzip2, and LZMA all apply, which is precisely why it decompresses faster but compresses less tightly.
• No encryption of any kind: the format has no password protection or content-hiding mechanism built into its design, unlike ZIP's optional AES extension or 7z's AES-256 support.
• No error correction, only detection: lzop's per-block Adler-32 or CRC-32 checksums can flag that a block is damaged but cannot reconstruct the lost data.
• No mainstream desktop tool support by default: 7-Zip and WinRAR generally don't include native LZO decompression, since the format is used almost exclusively in Linux, Unix, and embedded contexts.

Which Tools Actually Support Opening a Raw LZO File

The lzop utility itself, or a program built directly on its underlying LZO library, is the most reliable way to open a .lzo file, and it's typically a separate package on Linux distributions — commonly named `lzop` — rather than something preinstalled by default on every system. GNU tar integrates with it directly through a `--lzop` flag, which calls the external lzop binary automatically during archiving or extraction, and the same effect can be achieved on older tar versions with `--use-compress-program=lzop`.

LZO shows up inside several Linux kernel subsystems specifically because of its speed profile: the kernel's zram compressed-RAM block device documents LZO as a selectable compression backend, SquashFS has supported LZO compression since Linux kernel version 2.6.34, and Btrfs lists LZO alongside zlib and zstd as one of its three supported file-level compression algorithms. Embedded router firmware built on OpenWrt is another common real-world source of standalone .lzo and .tar.lzo files, again chosen specifically for fast decompression on modest embedded CPUs.

Outside those Linux and embedded contexts, general support narrows considerably. Mainstream Windows and macOS archive tools, and most mobile file-manager apps built around ZIP and RAR, typically have no dedicated LZO support at all, meaning a .lzo file that arrives from a Linux system frequently needs lzop specifically installed before it will open on a machine that doesn't already have it.

Why a .LZO File Sometimes Won't Open at All

The most common, well-documented complaint is a .lzo file downloaded from a Linux system, router firmware page, or embedded device simply refusing to open in 7-Zip, WinRAR, or a generic online extractor — this isn't file damage; those tools generally don't implement LZO decompression at all, since the format is used almost exclusively where lzop is already installed for exactly this purpose. Installing lzop, or a tool built specifically on its library, resolves this reliably.

A second recurring point of confusion involves a file actually being a .tar.lzo (or its shortened form .tzo) that got renamed or mislabeled as a plain .lzo — since a bare .lzo holds exactly one file, decompressing it and getting only one item back out, rather than a folder of files, is expected given the format, not a sign that anything is broken.

A third pattern shows up in scripts and Makefiles inside embedded-Linux build pipelines that hardcode a specific call to lzop as a fixed step in generating a firmware image — because tar and related tools generally have to be told explicitly which decompressor to use, rather than guessing from the file's bytes, editing an old script's expected compressor typically means editing that script directly rather than something that resolves itself automatically.

Raw LZO Set Against the General-Purpose Formats It Trades Against

Common Questions About Opening a Raw .LZO File

Why won't my .lzo file open in 7-Zip or WinRAR?
Because those tools generally don't include native LZO decompression — the format is used almost exclusively in Linux, Unix, and embedded contexts where lzop is already installed for exactly this reason, so a separate lzop-based tool is typically required.

Is a .lzo file the same thing as a .tar.lzo file?
No. A plain .lzo holds one file compressed by itself, while .tar.lzo (or its shorthand .tzo) is a full tar archive of multiple files compressed afterward — mixing the two up explains most unexpected results.

Why does LZO compress less than gzip or bzip2?
Because its default method skips the entropy-coding stage those formats add on top of their own matching pass — a deliberate trade that keeps decompression fast at the cost of a somewhat larger output file.

Where do .lzo files actually come from?
Mostly Linux and embedded systems: the kernel's zram subsystem, SquashFS since kernel 2.6.34, Btrfs, and embedded router firmware such as OpenWrt builds all document LZO as a selectable compression option specifically for its speed.

Does a .lzo file store the original filename and permissions?
Yes. Lzop's header records the original file's name, modification timestamp, and Unix permission bits directly, metadata that a compressor like plain DEFLATE output through some tools doesn't always carry.

Can I make LZO compress smaller by using a higher setting?
Somewhat. Lzop's `--best` flag switches to its more thorough lzo1x_999 method, which narrows the gap against gzip or 7-Zip, but LZO still skips entropy coding entirely even at that setting, so its ratio never fully catches up to formats that include it.