Convert TZO to TAR.GZ Online (Swapping LZO Speed for Gzip's Wider Support)

What a .TZO File Is Built to Do

A .tzo file is a tar archive compressed with lzop, the utility built around Markus Oberhumer's LZO compression library — lzop's own documentation lists .tzo as a shorthand for .tar.lzo, describing the identical underlying format. LZO's entire design prioritizes speed, particularly decompression speed, over how small the compressed output ends up, which is exactly why it shows up in embedded Linux firmware, router operating systems like OpenWrt, and backup pipelines where unpacking data fast matters more than shaving off extra megabytes.

Gzip, the format behind .tar.gz, takes a more general-purpose position: its DEFLATE algorithm, defined in RFC 1951, combines LZ77-style match replacement with Huffman coding, generally compressing better than LZO on typical data while still decompressing quickly, though not as fast as LZO specifically. Converting from .tzo to .tar.gz means fully decompressing the original LZO-compressed tar stream, then recompressing that same tar content with DEFLATE instead.

Neither compressor touches the tar layer underneath. Tar stores each file as a 512-byte header block describing its name, permissions, and size, followed by that file's data, one entry after another in a sequential stream with no built-in index, a structure dating back to writing archives onto magnetic tape. Whether LZO or gzip wraps around the finished stream, that internal layout is identical, which is why converting between the two compression methods always means fully unwinding the original compressed data back to plain tar before recompressing it differently.

Two Different Points on the Same Speed-Versus-Ratio Spectrum

Lzop's default lzo1x_1 method performs a comparatively simple Lempel-Ziv-style scan, replacing repeated byte sequences with shorter references and skipping the additional entropy-coding stage most other general-purpose compressors add afterward. DEFLATE adds exactly that missing stage: after its own LZ77 pass finds repeated sequences within a sliding window of recently seen bytes, it runs Huffman coding over the result, assigning shorter bit patterns to more frequently occurring symbols. That extra step is a meaningful part of why DEFLATE generally compresses tighter than LZO on the same input.

Both formats build integrity checking into their headers, though differently: lzop embeds a per-block checksum, Adler-32 by default or CRC-32 if the --crc32 option is used, while gzip stores a single CRC-32 checksum covering the entire decompressed data at the end of the file. Neither checksum can repair detected corruption on its own — both formats only flag that something is wrong, which is a limitation lzop's own documentation states directly and that applies equally to gzip's simpler single-checksum approach.

On most typical text-heavy or source-code-heavy data, DEFLATE's extra entropy-coding stage lets it compress noticeably tighter than LZO's simpler matching, though the gap is generally smaller than what bzip2 or xz would achieve over LZO on the same data — gzip sits in between LZO's speed-first approach and the heavier compression-first algorithms in terms of both speed and ratio.

What Rebuilding a TZO Archive as TAR.GZ Gains and Costs

• Gain — near-universal software support: gzip is installed by default on essentially every Linux, macOS, and Unix system, and read by every mainstream Windows archive tool, unlike LZO's much narrower tooling.
• Gain — a smaller file on most typical data: DEFLATE's Huffman coding stage generally compresses tighter than LZO's simpler matching scheme.
• Lose — LZO's fastest-in-class decompression: gzip decompresses quickly by general standards, but not as fast as LZO specifically, which matters if the archive feeds a genuinely time-critical process.
• Gain — mature, decades-old tooling: gzip has been a Unix default since the early 1990s, giving it a longer track record and broader library support across programming languages than LZO.
• Lose — LZO's very low CPU and memory overhead: DEFLATE needs somewhat more processing time and memory than LZO's lighter scan, a real difference on the most constrained embedded hardware.
• Unchanged — the actual file contents: both LZO and gzip are lossless, so extracted files remain identical regardless of which algorithm compressed them.

Documented Support Gaps Between These Two Formats

Reading a .tzo file requires the lzop utility specifically, or GNU tar used with its --lzop flag, since mainstream Windows and macOS archive managers generally don't include LZO decompression by default — a real, current limitation that keeps .tzo files mostly confined to Linux, Unix, and embedded-systems environments that already have lzop installed for a specific purpose.

Gzip sits at the opposite end of that spectrum. GNU tar supports it directly through the -z or --gzip flag, it's part of the default installation on virtually every Linux and macOS system, and 7-Zip, WinRAR, and PeaZip all read and write .tar.gz archives on Windows without any extra setup. This gap is precisely why .tzo-to-.tar.gz conversions get requested in practice — not because gzip always compresses meaningfully better, but because it's the one format almost every recipient can already open.

Programming language ecosystems reflect the same gap: Python's standard library, Java's standard library, and most other mainstream languages include built-in gzip support without any extra package, while reading or writing LZO-compressed data generally requires a separate, less commonly maintained third-party binding. This matters for anyone building automated tooling around either format, since gzip support can usually be assumed to already be available, while LZO support typically has to be added deliberately.

Real Reports From Embedded and Cross-Platform Workflows

A recurring complaint in cross-platform development threads involves a .tzo file produced on a Linux build server that a Windows-based colleague can't open at all, since neither 7-Zip nor WinRAR includes native LZO decompression — the documented fix is either installing a Windows-compatible lzop build or having the Linux side rebuild the archive as .tar.gz before sharing it more broadly.

A second, opposite report shows up specifically in embedded-firmware discussions: an image rebuilt as .tar.gz for easier distribution or archival can turn out to be unusable for actual deployment if the target device's bootloader was written to decompress LZO-compressed data specifically and has no gzip decoder built into its limited firmware. In these cases, the version shared with a team for review and the version actually flashed onto the hardware legitimately need to stay in two different formats.

A third pattern involves noticeable, though usually modest, differences in resulting file size that surprise some users — because LZO's compression ratio isn't dramatically far behind gzip's on many kinds of data, someone expecting a large size reduction after this specific conversion sometimes sees only a small improvement, especially compared with the bigger gains typically reported when converting the same archive to bzip2 or xz instead.

A fourth, more procedural complaint involves scripts and automation pipelines written around a specific tar flag that assume a fixed compression method — a script hardcoded to call tar --lzop for extraction will simply fail against a .tar.gz file rebuilt from that same content, since tar needs to be told which compression method to expect, or, in many modern GNU tar versions, relies on automatic detection based on the file's extension or header bytes. Updating any downstream scripts to match the new format, rather than assuming the flag can stay the same, is a real, practical step this conversion requires.

LZO's Narrow Speed Focus Set Beside Gzip's Broad Default Status

Questions About Replacing LZO Compression With Gzip

How much smaller will my archive get after converting from .tzo to .tar.gz?
Usually somewhat smaller, though the gap between LZO and gzip's DEFLATE is more modest than switching to bzip2 or xz, which tend to compress meaningfully tighter than gzip does.

Why can't I open a .tzo file with a standard Windows archive tool?
Mainstream tools like 7-Zip and WinRAR generally don't include native LZO decompression support. The lzop utility, or GNU tar's --lzop flag, is needed to read the original archive first.

Is gzip's decompression as fast as LZO's?
Not quite. Gzip decompresses quickly by general standards, but LZO is specifically optimized to be faster still, which is the entire reason LZO gets chosen over gzip in time-critical, especially embedded, contexts.

Should I convert a firmware image meant for a device's bootloader to gzip?
Not for the version actually deployed. If the bootloader expects LZO-compressed data directly, converting the deployed image to gzip will likely make it unusable on that specific hardware.

Does this conversion change any of the actual files?
No. Both LZO and gzip's DEFLATE are lossless compression methods, so every file extracted afterward is byte-for-byte identical to what was originally inside the .tzo archive.

Will my old extraction scripts still work after this conversion?
Not automatically. A script written to call tar with a flag specific to LZO decompression needs updating to expect gzip instead, since the two compression methods aren't interchangeable at the command level.