Convert LZO to ZIP Online (From a Linux-Only Format to One Every Desktop Opens)

A Bare .lzo File Holds Exactly One File, Not a Folder of Them

A plain .lzo file is a single file compressed with lzop, the command-line tool Markus Oberhumer built around his own LZO compression library and first released on August 10, 1997. Lzop's documentation is specific about this: like gzip, it compresses one file at a time and produces one compressed output per input, without any built-in concept of bundling several files into one archive. That bundling job belongs to tar — a folder of files compressed this way becomes .tar.lzo (or the shorthand .tzo), never a bare .lzo. Converting a raw .lzo to ZIP means decompressing that one file back to its original bytes with lzop, then placing the recovered file into a ZIP container, which uses PKWARE's own local-header-plus-central-directory structure, defined in the public APPNOTE.TXT specification PKWARE still updates today (current version 6.3.9).

LZO's documented design priority is decompression speed above nearly everything else, including how small the output file ends up. Its default lzo1x_1 method performs a simplified Lempel-Ziv-style scan for repeated byte sequences and deliberately skips the entropy-coding stage that ZIP's default DEFLATE method applies on top of its own matching pass. Skipping that stage is exactly why LZO decompresses faster than DEFLATE but generally produces a larger file for the same input.

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 magic-byte signature so a corrupted or text-mode-mangled transfer fails loudly instead of silently. The header that follows records the LZO method and level used along with the file's original name, timestamp, and Unix permission bits — details a ZIP archive instead tracks through its own central directory entries and, inconsistently across different ZIP tools, an extended attribute field for Unix mode bits.

ZIP's Central Directory Against LZO's Single Continuous Stream

ZIP's central directory, sitting at the very end of the archive, lists every entry's name, size, and exact byte offset, which is what lets any ZIP-reading program jump straight to the part of the file it needs without scanning through everything else first. A bare .lzo file has no equivalent structure to jump around in, because it was never designed to hold more than one entry — there's nothing to index. That structural difference is also why ZIP naturally scales to holding many files with fast lookups, while a raw .lzo stays fundamentally single-purpose: one compressed file, decompressed from front to back.

ZIP's default compression method is DEFLATE, the same LZ77-plus-Huffman-coding algorithm used in gzip and PNG, though ZIP's specification also allows storing files uncompressed (method 0) or, through the WinZip/7-Zip AES extension, marking an entry as encrypted (method 99). None of LZO's speed-first design carries over once a file is rebuilt as a ZIP — the archive instead follows whatever compression and encryption settings the ZIP-creation tool applies.

The two formats also verify data differently. Lzop splits its compressed output into blocks and gives each one its own checksum, using the faster Adler-32 algorithm by default or CRC-32 if the --crc32 option is set when the file is created, so a single damaged block doesn't necessarily block reading the rest of the file. ZIP instead stores one CRC-32 value per entry in its local header and central directory, computed over that entry's full decompressed content — a per-file check rather than lzop's per-block one, but still only capable of detecting corruption, not repairing it, in either format.

What Rebuilding an LZO File as a ZIP Actually Trades Away

• Gain — native support on Windows and macOS: both operating systems' file managers open ZIP directly, while neither includes LZO decompression out of the box.
• Gain — the option to add more files later: a ZIP's central directory structure supports many entries, unlike a bare .lzo file, which was only ever built for one.
• Lose — LZO's fast decompression: ZIP's default DEFLATE method adds a Huffman-coding stage that LZO's design specifically skips to stay fast.
• Lose — LZO's very light CPU and memory footprint: DEFLATE is heavier to run, which matters on the constrained hardware LZO is usually chosen for.
• Gain, inconsistently — Unix permission bits: ZIP can store them in an extended attribute field, but support varies enough between ZIP tools that preservation isn't guaranteed.
• Lose — nothing about the file's actual content: once fully decompressed and rebuilt, the recovered file is byte-for-byte identical; only the surrounding compression and container changed.

Where LZO Support Actually Exists Versus Where ZIP Just Works

ZIP support has been built into Windows since Windows XP's built-in Compressed Folders feature, and into macOS's Archive Utility for just as long, with 7-Zip, PeaZip, and the Info-ZIP command-line tools all handling it freely on every major platform besides. LZO support is far narrower: mainstream tools like 7-Zip and WinRAR generally don't include native LZO decompression, and lzop itself is typically a separate package on Linux distributions rather than something preinstalled by default, since the format is used almost exclusively in Linux, Unix, and embedded contexts.

That gap is exactly why converting a raw .lzo to ZIP has practical value. Files compressed with LZO commonly come from places chosen specifically for its speed — the Linux kernel's zram subsystem, SquashFS since kernel version 2.6.34, Btrfs (which documents LZO as one of its three supported compression algorithms alongside zlib and zstd), and embedded router firmware such as OpenWrt builds. None of those origins guarantee the person receiving the file has lzop installed, while a ZIP opens without any extra software on almost any desktop machine.

Licensing is a further, separate difference worth noting: the LZO library and lzop itself are distributed under the GNU General Public License, version 2 or later, a copyleft license some proprietary embedded-firmware projects have documented weighing carefully because of its redistribution obligations. ZIP carries no such requirement — PKWARE's APPNOTE.TXT specification is published openly, and the DEFLATE algorithm behind it is free of licensing restrictions, which is part of why ZIP-writing tools exist for essentially every platform without any legal friction attached.

The Actual Complaints People Report With Raw LZO Files

A recurring, documented problem is a .lzo file downloaded from a Linux system, router firmware page, or embedded device simply refusing to open in Windows Explorer, 7-Zip, or WinRAR — this isn't file damage; those tools generally don't include LZO support at all, since the format almost never appears outside Linux and embedded contexts where lzop is already installed for exactly this purpose.

A second common point of confusion involves expecting a bare .lzo to contain multiple files and being surprised that decompressing it produces only one — a plain .lzo was only ever built to hold a single file; a folder of files needs to go through tar first, producing .tar.lzo (or .tzo), which is a completely different, multi-file format despite the similar name.

A third issue shows up around Unix permission bits after the ZIP is created: lzop's header reliably stores the original file's permission bits, but ZIP's extended attribute field for the same data isn't consistently written or read across every ZIP tool, so a file that was executable on Linux can come through the ZIP as a plain, non-executable file depending on which archiver performed the conversion.

LZO's Narrow Reach Set Against ZIP's Near-Universal One

Questions About Turning a Raw LZO File Into a ZIP

Why won't my .lzo file open in File Explorer or 7-Zip?
Because those tools generally don't include native LZO decompression at all — the format is used almost exclusively in Linux and embedded contexts where lzop is already available, so a separate lzop-based tool is typically needed first.

Is a bare .lzo file the same as a .tar.lzo file?
No. A plain .lzo holds a single file compressed by itself, while .tar.lzo (or .tzo) is a full tar archive of multiple files compressed afterward — they're built for different purposes despite the similar extension.

Will converting to ZIP preserve Linux file permissions?
Not reliably. ZIP has an extended attribute field that can hold Unix permission bits, but support for writing and reading it varies between ZIP tools, so results depend on which software performs the conversion.

Does converting LZO to ZIP change the actual file content?
No. Once the original file is fully decompressed and rebuilt inside the ZIP, its bytes come out identical — only the compression method and container around it changed.

Why does LZO exist if it compresses worse than ZIP's DEFLATE?
Because LZO trades compression ratio for decompression speed on purpose — it's built into speed-sensitive Linux kernel features like zram and Btrfs, where fast unpacking matters more than the smallest possible file.