Convert TZO to ZIP Online (From an LZO Tarball to PKWARE's Universal Container)

Where a .TZO Archive Comes From

A .tzo file is a tar archive compressed with lzop, a tool built on Markus Oberhumer's LZO compression library. Lzop's own documentation lists .tzo specifically as a shorthand for .tar.lzo, describing the same underlying format under a shorter name. LZO's design prioritizes decompression speed above almost everything else, at a real cost to compression ratio, which is exactly why it turns up in embedded Linux firmware, router operating systems like OpenWrt, and time-critical backup pipelines rather than in general-purpose file sharing.

ZIP, defined in PKWARE's APPNOTE.TXT specification since 1989, is built for an entirely different purpose: broad, native compatibility across operating systems, with each file compressed and indexed individually rather than as part of one continuous stream. Converting a .tzo file to .zip means something more involved than swapping one compression algorithm for another — it means unpacking the whole tar-plus-LZO arrangement and rebuilding the contents inside a fundamentally different kind of container.

A Sequential Stream Versus an Indexed Container

Tar's structure is sequential: every file inside gets a 512-byte header block recording its name, permissions, and size, immediately followed by that file's data, with entries simply following each other in order and no built-in index of what's inside or where anything sits — a design that traces back to writing data onto magnetic tape, where sequential access was the only option available anyway. LZO compression, applied afterward by lzop, wraps around that entire finished tar stream as a single pass, with no awareness of the individual file boundaries inside it.

ZIP works the opposite way: each file gets compressed and stored as its own distinct entry, complete with its own local header, and a central directory at the end of the archive lists every entry's name, size, and exact byte offset. That structural difference is why a ZIP reader can extract one specific file directly, without touching anything else in the archive, while getting one file out of a compressed tar stream generally requires decompressing from the very beginning — a genuine practical distinction, not a cosmetic one.

Because of that structural gap, this conversion requires fully decompressing the LZO layer, reading each file back out of the sequential tar layout underneath, and reassembling everything as individually compressed ZIP entries with their own headers plus a freshly built central directory — a genuine rebuild between two different container philosophies, not a simple recompression step.

This also means the resulting ZIP file's structure has no direct trace of the tar layer it came from. Once rebuilt, there's no remaining tar header data, no single continuous stream, and no LZO checksum blocks — the ZIP archive is a genuinely fresh container built from the extracted files themselves, which is a real, structural difference from formats like .tar.gz or .tar.bz2 that keep the original tar layer intact underneath a different compression method.

What Moving From TZO to ZIP Gains and Loses

• Gain — native support on Windows and macOS: both operating systems open ZIP files without installing anything extra, unlike .tzo, which needs dedicated Unix-heritage tooling.
• Gain — per-file random access: ZIP's central directory allows extracting a single specific file directly, without decompressing everything that came before it in the archive.
• Gain — typically better compression than LZO: ZIP's default DEFLATE method generally compresses tighter than LZO's speed-focused, simpler matching scheme on most data.
• Lose — Unix file permission metadata: tar headers natively record Unix permission bits and ownership; standard ZIP entries don't consistently preserve that same metadata across every tool.
• Lose — LZO's fastest-in-class decompression speed: ZIP's DEFLATE decompresses quickly by general standards, but not as fast as LZO on hardware where that specifically matters.
• Unchanged — the actual file contents: both LZO and DEFLATE are lossless, so anything extracted from the rebuilt ZIP is identical, byte for byte, to what was originally inside the .tzo file.

Where Each Format Actually Works Without Extra Software

Opening a .tzo file requires the lzop utility itself, or GNU tar used with its --lzop flag, since mainstream Windows and macOS archive managers generally don't support LZO decompression by default — a real, current gap that keeps .tzo files mostly confined to Linux, Unix, and embedded-systems environments where lzop is already installed.

ZIP sits at the opposite end of that spectrum entirely: Windows has included native ZIP support since Windows XP through its integrated Compressed Folders feature, macOS has had built-in ZIP support through Finder and Archive Utility for just as long, and mobile operating systems generally handle ZIP files without any additional app. This is precisely the reason .tzo-to-.zip conversions get requested at all — not because ZIP is technically superior, but because it's the one format almost every recipient, on almost any device, can already open.

Programming language ecosystems show the same pattern: reading and writing ZIP archives is built into the standard library of Python, Java, and most other mainstream languages, while working with LZO-compressed data generally requires a separate, less commonly maintained binding. Anyone building automated tooling around either format can generally assume ZIP support is already available, while LZO support usually needs to be added deliberately.

Documented Complaints From Cross-Platform Sharing

A recurring report in embedded-development and cross-platform threads involves a .tzo file created on a Linux build server that a Windows-based reviewer has no way to open, sometimes mistaking the unfamiliar extension entirely for a typo or an unrelated file type. The consistent, documented fix is converting the archive to ZIP before sharing it, rather than expecting every recipient to install lzop just to look at a handful of files.

A second real issue involves lost Unix file permissions after conversion: executable scripts that had their execute bit set inside the original tar archive sometimes lose that bit once repackaged as a ZIP, because not every ZIP-writing tool preserves Unix permission metadata consistently, and not every extraction tool on the receiving end reads it even when it is present. Checking permissions manually on any scripts pulled from a converted archive, rather than assuming they transferred automatically, is a documented, worthwhile step.

A third pattern involves symbolic links specifically: tar can store a symlink as its own distinct entry type recording just the link's target path, but the base ZIP specification has no directly equivalent native entry type, so different ZIP-writing tools handle this differently — some resolve the symlink into a full copy of its target file during conversion, others may drop it. Anyone converting an archive that contains symlinks should confirm how the specific tool being used actually handles them, since the outcome genuinely varies.

A fourth, narrower complaint comes from embedded-development teams specifically: converting a firmware image from .tzo to .zip for easier internal distribution is fine for sharing purposes, but the version that actually gets flashed onto the target device generally needs to stay in its original LZO-compressed form, since the device's bootloader was written to decompress that specific format quickly and typically has no ZIP or DEFLATE decoder available at all in its limited firmware.

LZO-Compressed Tarballs Set Beside PKWARE's Indexed Container

Common Questions About Bringing LZO Archives Into ZIP

Why can't I just open a .tzo file the way I open a ZIP?
Windows and macOS have no built-in support for LZO-based compression. The lzop utility, or GNU tar's --lzop flag, is needed first, whereas ZIP has been natively supported on both operating systems for decades.

Will my file permissions survive this conversion?
Not always reliably. Tar stores Unix permission and ownership metadata natively, but standard ZIP entries don't consistently preserve that same metadata across every tool, so checking permissions after extraction is worth doing.

What happens to symbolic links during this conversion?
It depends on the tool. Tar has a native symlink entry type; ZIP's base specification doesn't define a direct equivalent, so some tools convert a symlink into a full copy of its target file, and others may drop it.

Does converting to ZIP lose any of the actual data?
No. Both LZO and ZIP's default DEFLATE method are lossless, so every file extracted afterward is identical to the original, byte for byte.

Is .tzo the same thing as .tar.lzo?
Yes. Lzop's own documentation describes .tzo specifically as a shorter substitute for the .tar.lzo extension, referring to the identical format.

Should I convert an embedded firmware image to ZIP before deploying it?
Only for distributing it to people. The actual version flashed onto the device usually needs to stay in its original LZO-compressed form, since the bootloader typically has no ZIP or DEFLATE decoder built in.