Convert Any File to LZO Online (Producing a Single Speed-Tuned Compressed File)

Compressing One File at a Time With lzop's Speed-First LZO Algorithm

Producing a .lzo file means running a single file through lzop, the command-line utility Markus Oberhumer built around his own LZO (Lempel-Ziv-Oberhumer) compression library and first released on August 10, 1997. Lzop's own documentation describes it working exactly the way gzip does on a lone file: one input goes in, one compressed output comes out, with no built-in concept of an archive containing several entries. That single-file constraint is a defining, deliberate feature of the raw .lzo format, not an accidental gap.

Lzop's default compression method, lzo1x_1, performs a comparatively simple Lempel-Ziv-style scan for repeated byte sequences and deliberately skips the entropy-coding stage — something functionally similar to Huffman coding — that gzip's DEFLATE, bzip2's Burrows-Wheeler-based pipeline, and LZMA-based compressors all apply on top of their own matching. Skipping that stage is the specific, mechanical reason LZO decompresses faster than those alternatives: there's simply less decoding work left once the matched sequences are expanded back out.

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 pack on raw speed and near the back on how much smaller the output gets — a documented, measurable trade-off. Compressing an entire Linux kernel source tree with lzop has been reported to take roughly one second, a task that runs noticeably longer with gzip and substantially longer with bzip2 or xz at higher compression settings, which is the kind of speed gap that matters when compression sits inside a time-sensitive process.

Every file lzop produces opens with a fixed nine-byte magic sequence — 0x89 0x4C 0x5A 0x4F 0x00 0x0D 0x0A 0x1A 0x0A — styled deliberately after PNG's own signature so a corrupted or text-mode-mangled transfer fails loudly rather than silently. The header that follows carries the LZO method and level used, plus the source file's original name, modification timestamp, and Unix permission bits, all of which get restored automatically when the file is decompressed.

Why This Format Stays Deliberately Single-File Rather Than a Bundle

When more than one file needs to end up in a single output, lzop's documentation is direct about the correct approach: run tar first to bundle everything into one archive, then compress that archive with lzop, producing .tar.lzo, or its shorthand .tzo, rather than a bare .lzo. Converting multiple input files to a raw .lzo target specifically therefore means either compressing each file into its own separate .lzo file, one per input, or that the requested output isn't actually the narrower single-file format at all but the tar-wrapped .tzo variant.

This distinction matters in practice because the two output types serve genuinely different purposes. A folder of log files, source code, or photos being archived together calls for .tzo, where tar's own header blocks track each entry's name and permissions before lzop compresses the whole bundle. A single large file — a disk image, a database dump, a firmware blob — is exactly the case a bare .lzo file was built for, with lzop's own header carrying that one file's metadata directly, without tar's additional layer of indirection.

Lzop also documents higher-effort settings beyond its speed-first default, up to lzo1x_999 accessible through the `--best` flag, which spends more CPU time searching for matches and narrows, without eliminating, the ratio gap against DEFLATE or LZMA-based compressors. Choosing a higher method still doesn't add entropy coding at any level — LZO's ceiling on compression stays below what gzip or 7-Zip routinely achieve on the same data, regardless of which lzo1x variant is selected.

What Choosing Raw LZO Output Gains and Costs

• Gain — genuinely fast decompression: LZO's simplified decoding path is markedly quicker than DEFLATE, bzip2, or LZMA-based decompression on the same data, which matters directly for embedded devices or time-critical extraction.
• Lose — a meaningfully smaller file than gzip, bzip2, or xz would produce: LZO's simpler matching finds fewer exploitable repetitions, so a .lzo file is typically larger than the same data compressed with those alternatives.
• Gain — low memory and CPU demand during compression: LZO's design needs less working memory than LZMA-based compression specifically, a real advantage on constrained or embedded hardware.
• Gain — built-in, granular corruption detection: lzop's per-block checksums (Adler-32 by default, or CRC-32 with the `--crc32` option) let extraction flag damage without needing a separate checksum tool.
• Lose — the ability to hold more than one file: a bare .lzo output is strictly single-file; anything requiring multiple entries needs the .tzo (tar.lzo) format instead.
• Lose — broad mainstream tool compatibility: Windows and macOS have no native LZO support, and 7-Zip and WinRAR generally don't implement it either, narrowing who can open the result without installing lzop specifically.

Which Tools Can Actually Produce a Raw LZO File

The lzop utility itself is the direct, documented way to produce a .lzo file, available as a package on most Linux distributions (commonly named `lzop`) and buildable from source on other Unix-like systems. It is not preinstalled by default nearly as widely as gzip or bzip2, since real demand for creating new LZO-compressed files centers on Linux, Unix, and embedded-systems contexts rather than general desktop use.

Mainstream Windows and macOS archive tools — 7-Zip, WinRAR, and the built-in compression features of both operating systems — do not document support for writing LZO-compressed output, a real, current gap compared with how broadly those same tools handle gzip, bzip2, and ZIP. Producing a .lzo file in practice is therefore almost always a deliberate step inside a Linux or embedded-systems workflow that already has lzop installed for a specific purpose, rather than a general-purpose choice made whenever any compressed format would otherwise do.

The Real Reasons Someone Targets This Specific Speed-Tuned Format

A well-documented, recurring reason to produce a raw .lzo file specifically involves embedded Linux systems — including OpenWrt-style router firmware — where a single kernel image or root filesystem blob gets compressed with an LZO-family algorithm precisely because decompression happens on every boot, on hardware with limited CPU power, and a faster decompression step at boot time is worth more there than a smaller stored image would be.

A second real scenario involves compressing a single large file — a database dump, a disk image, a large log file — inside a backup or replication pipeline where the compression step must not become a bottleneck in a tight processing window; lzop's documented speed advantage over gzip or bzip2 translates directly into a shorter window, which matters more than the extra megabytes a tighter compressor would shave off.

A third, narrower case involves matching an existing toolchain or kernel subsystem that already expects LZO-compressed input specifically — the Linux kernel's zram compressed-RAM subsystem, SquashFS since kernel version 2.6.34, and Btrfs, which lists LZO alongside zlib and zstd as one of its three supported compression algorithms, are all documented contexts built around LZO's speed profile rather than a general-purpose compressor's better ratio.

A fourth case involves real-time or continuous data streams where compression has to keep pace with data arriving faster than a heavier algorithm could process it — a scenario where even bzip2's or xz's better compression ratio isn't a usable option if the algorithm can't sustain the incoming data rate, making LZO's speed the deciding factor rather than one trade-off weighed among several equally viable ones.

One Fast File Versus a Gzip-Compressed Bundle, Side by Side

Common Questions About Creating a New Raw LZO File

Can I compress a whole folder into one .lzo file?
Not directly. A bare .lzo file holds exactly one compressed stream; bundling a folder requires tar first, which produces .tar.lzo (or .tzo), a related but different format.

Why would I choose raw LZO over a more common format like ZIP or gzip?
Mainly for decompression speed — LZO decompresses noticeably faster than DEFLATE, bzip2, or LZMA-based formats, which matters when the extraction step sits inside a time-critical process like device boot-up.

Will my .lzo file be bigger than the same data compressed with gzip?
Usually, yes. LZO's simpler matching-only approach generally produces a larger file than DEFLATE, bzip2, or LZMA on the same input, which is the direct trade-off for its faster decompression.

Can Windows or macOS open a .lzo file without extra software?
No. Neither operating system includes native LZO support, and mainstream tools like 7-Zip and WinRAR generally don't implement it either, so the lzop utility itself is typically required.

Does compressing to LZO lose any of my original data?
No. LZO, like gzip's DEFLATE or bzip2's BWT-based method, is a lossless compression algorithm, so decompressing later restores the original file exactly as it was.

Does using lzop's `--best` flag make a real difference in file size?
Some. The lzo1x_999 method it enables searches harder for matches and narrows the gap against gzip or 7-Zip, but LZO still skips entropy coding entirely at every setting, so the difference is incremental rather than closing the gap completely.